Digital Legacy Planning for Your Notes: How to Leave an Encrypted Vault Your Executor Can Actually Open

She knew the password. That was the part she kept returning to, in the small hours, in a flat in another country with her father’s laptop open on the kitchen table and a mug gone cold beside it. She knew the password because he had told her, years earlier, in the practical tone he used for boiler instructions and insurance renewals. He had written it down once, too, on a card in a desk drawer, and she had photographed that card before she moved abroad so she would have it if he ever forgot. When the call came, and then the flight she could not get, and then the quiet administrative weather that follows a death — the forms, the registrar, the undertaker asking gentle questions she had to answer from memory — she assumed that at least this part would be simple. She would sign in, she would find the household accounts, she would locate the photographs, she would do the competent, loving work of closing a life down in order.

The sign-in screen accepted the password. Then it asked for something else.

It asked for a code sent to his phone number. The number still existed on paper. It existed in her contacts. It existed on the death notification she had already given the network, because someone well-meaning at home, trying to be helpful and stop bills accruing, had called the provider and cancelled the contract two days after he died. Cancellation felt tidy. Cancellation felt responsible. Cancellation also severed, in one phone call, the single thread that almost every other account in his life was tied to. The code went nowhere she could reach. The alternative the screen offered was a code sent to a trusted device. The trusted device was his phone, on a bedside table in an empty house in another time zone. She knew where the phone was. She did not know the passcode to unlock it. A password for an account and a passcode for a device are not cousins. They are different locks on different doors, made by different companies, answering to different rules, and knowing one gives you no claim on the other.

She tried the recovery path. Recovery asked questions whose answers had once been obvious and were now archaeological. It wanted her to confirm a device that had signed in recently. It wanted access to an email account that itself wanted a code. Each door, opened in imagination, revealed another door behind it, each one reasonable in isolation, each one designed for a living owner who had merely forgotten something, not for a daughter who had remembered everything she was given and still could not get in.

The photographs were the hardest loss to explain to relatives, because they were not, in any physical sense, lost. There was a drive in the house. There were backups she half-remembered him mentioning. There were years of family pictures — birthdays in gardens, a wedding where everyone looked impossibly young, his own parents standing stiffly in front of a house that no longer exists — organised, he had always said, properly organised, not like other people’s camera rolls. But the drive was tied into an account ecosystem. The library opened through software that wanted his sign-in. The sign-in wanted his phone. His phone wanted a passcode nobody had ever thought to share, because sharing a phone passcode feels intimate in a way that sharing an email password somehow does not, even though, after death, it is the phone passcode that turns out to matter more.

Friends offered suggestions the way people do when a technical problem is standing in for grief. Try his birthday. Try the dog’s name. Try plugging the drive into another computer. She tried, carefully at first, then with the growing awareness that too many wrong attempts can themselves become a lock, that systems count failures as well as successes, and that a device protecting its owner in life will go on protecting him, indifferently, after he is gone. Nothing about the system was malfunctioning. That is what made it so difficult to argue with. Every prompt was doing exactly what it had been built to do: refusing entry to anyone who could not complete a chain of proof that had been designed around a living person holding a particular phone, in a particular place, able to receive a particular code within a particular minute.

On the third evening she sat with a notebook and wrote down what she actually knew. Not what she could access — what she knew. The names of the energy company. The rough month the house insurance renewed. That there was a will, somewhere, possibly with a solicitor whose name she almost remembered. That he paid some bills by direct debit and others, stubbornly, by logging in and pressing pay, because he liked to see them go. That there were photographs. That there was a password. The list was both longer than she feared and useless in the precise places where usefulness mattered. Knowledge, she was learning, is not the same as access, and a family can inherit a great deal of the first while being granted none of the second.

This shape of story recurs, with different countries and different companies, whenever people describe trying to recover a parent’s digital life after a death. The details rotate — sometimes it is a spouse rather than a child, sometimes the person is in the same house rather than abroad, sometimes the phone has not been cancelled but has simply run out of charge and its number has been allowed to lapse months later — but the structure holds. Someone responsible, someone trusted, someone who was given the password on purpose, discovers that the password was only the first sentence of a much longer set of instructions that nobody wrote down. The systems do not ask, are you his daughter? They ask, can you receive this code? The systems do not ask, do you have a death certificate? They ask, is this a trusted device? Love and legal relationship, the two things a family actually has, are not inputs the sign-in screen accepts.

It would be comforting to treat this as a story about one family’s oversight, about a phone contract cancelled too quickly and a passcode never shared. Comforting, and mostly wrong. The same failure waits inside households that did share passcodes, because numbers get changed, devices get replaced, recovery flows get redesigned, and a plan that consists of a single secret whispered to a single person decays quietly while everyone is alive and nothing appears to be wrong. A password shared in 2019 describes the locks of 2019. It says nothing reliable about the locks of the year someone dies.

So the question this article exists to answer is not how to guess better, or how to recover harder, or which support line to plead with once the chain has already broken. Those questions matter in a crisis, and later sections will be honest about how narrow the answers usually are. The prior question, the one a parent can still act on while there is time, is different and quieter. What should the parent have left instead of passwords? Not a longer list of passwords. Not a more secret list of passwords. Something that survives a cancelled number, a locked phone, a forgotten recovery key, and the simple passage of years — something an executor can actually open, on an ordinary computer, without needing the dead person’s devices to vouch for them. That is the design problem of digital legacy planning for notes, and it is the problem the rest of this article works through, step by practical step.

The password was correct and it still did not matter

A password proves that someone, at some moment, typed the right sequence. It has never, on its own, proved who that someone is, and modern account security is built entirely around that distinction. When you create an account, the password is the shared secret you and the company agree on. When you return to that account years later, especially from a new device, a new browser, a new country, or after a long silence, the company treats the correct password as the beginning of the conversation rather than the end of it. That is not bureaucracy layered on top of security. That is the security, working as intended, and it is why an executor holding a perfectly accurate password so often gets no further than a stranger who guessed wrong.

The first link in the chain after the password is usually a second factor, and the second factor is usually a phone. A code arrives by text message or through an authenticator, and whoever holds the phone is treated, for the purposes of that minute, as the account’s owner. Families understand this instinctively while everyone is alive: the code goes to Dad’s phone because it is Dad’s account. After a death, the logic inverts and becomes an obstacle course. If the phone is locked, the code may arrive and remain unreadable behind the lock screen. If the contract has been cancelled, the code is sent to a number that no longer terminates anywhere the family controls. If the number has been allowed to lapse and is later reclaimed by the network, it will in time be issued to someone else entirely — a stranger who has no malice and no connection, but who now stands, in the system’s eyes, closer to the account than the executor does, because the stranger can receive its codes and the executor cannot. No warning is sent to the family when a number changes hands. The account simply begins trusting a different person.

Authenticator apps remove the dependence on the phone network and replace it with a dependence on a single device. The rotating codes live inside an app on the phone that was set up, often years earlier, in a process nobody remembers. There is no drawer to open and find them. If the setup produced backup codes or a recovery secret, those artefacts matter enormously; if it did not, or if they were saved inside the very account they protect, the executor is in the familiar circular position of needing to be inside in order to get inside. Password managers have the same shape at one remove. A family may know that everything is in the vault, which is true and useless in equal measure if opening the vault requires a master password plus a second factor plus a trusted device, and only two of those three things survived.

Trusted devices deserve their own attention because they are invisible while they work. A laptop that signed in every week for years is trusted almost by definition; the company stops challenging it because its pattern of use is itself a credential. An executor abroad, signing in from an unfamiliar network on an unfamiliar machine, presents the opposite pattern in every particular. The system is not being stubborn when it escalates. It is reading the situation correctly by its own lights: correct password, wrong place, wrong device, long silence, high-value account. Those are the contours of an account takeover attempt, and the defences against takeover do not contain an exception for bereavement. There is no checkbox on the challenge screen for grief.

Underneath all of this sits a confusion of vocabulary that causes real harm in families, because the words sound interchangeable and are not. A password unlocks an account with a company. A passcode unlocks a physical device in your hand. A PIN unlocks a card or a SIM or a single app. A recovery key — a long, randomly generated string some services issue at setup — can rebuild access when everything else has failed, which also means it is usually the one artefact nobody printed, nobody stored separately, and nobody can reconstruct from memory. Each of these secrets guards a different layer, and a legacy plan that records only the first layer has recorded the layer most likely to be overruled by the others. People leave passwords because passwords are what they type every day. They forget to leave recovery keys because recovery keys are what they were shown once, on a setup screen, on an afternoon when nothing felt urgent.

There is a harder version of this story that plays out inside password managers themselves, and it is worth telling plainly because it corrects a widespread assumption: that a reputable company, presented with a death certificate and a sympathetic explanation, will somehow open the vault as an act of decency. In discussions among users of zero-knowledge password managers, a recurring account describes a father who died with everything — banking, utilities, subscriptions, the whole administrative skeleton of a household — inside his password vault, and a family that had been told, in good faith, that the vault was the plan. What they could not find, after his death, was the printed emergency kit the service tells every user to keep: the document that carries the account details and the additional secret key without which the master password alone is insufficient. They searched the house. They searched his files. The kit, if it was ever printed, was not where a grieving family could locate it.

The company’s answer, when it came, was not cruelty and not indifference. It was architecture. A zero-knowledge design means the company holds only an encrypted vault it cannot read. It does not possess the keys. It cannot reset them into existence, cannot peer inside to confirm that a particular bill is in there, cannot hand a copy to an executor even if every lawyer in the country writes in support. Presented with proof of death, the company could express sympathy and explain the design, and those were, in substance, the same act. The encryption that had protected the father from breaches, from rogue employees, from compelled disclosure, protected his vault from his own children with exactly the same indifference. Good encryption does not ask why you want in.

What followed, in that family’s account, is the part executors recognise most bitterly. The bills did not announce themselves. They revealed themselves one by one, as they charged. A card payment would leave the account and the family would learn, retrospectively, that a subscription existed. An insurance premium would renew or fail. A service would send a final notice to an email account nobody could open. Reconstructing a household’s obligations from the outside, by watching money leave, is detective work conducted at the worst possible time, with incomplete evidence, against deadlines set by companies that do not know a death has occurred. The vault had been intended to prevent exactly that scramble. Because one printed sheet was missing, it caused it.

Notice what the lesson is not. The lesson is not that password managers are a mistake, or that zero-knowledge encryption is too strong for ordinary families. For a living user, that design is among the most protective choices available, and this article will argue later for encryption just as uncompromising in a legacy vault. The lesson is narrower and more useful: any plan whose success depends on a single artefact — a printed kit in a particular drawer, a recovery key in a particular file, a phone remaining charged and trusted and in the family home — is a plan with a single point of failure, and death is exceptionally good at finding single points of failure. Houses are cleared. Drawers are emptied by well-meaning relatives. Phones are wiped for return to a network. The artefact survives only if the plan treats it as what it is: not paperwork, but a key, stored with the deliberate redundancy keys deserve.

An executor, then, does not need more passwords. An executor needs a path that does not run through the dead person’s live accounts at all for the information that matters most — and a clear-eyed understanding, for everything that must still run through those accounts, of how fragile each path is and how quickly it closes. The password being correct and still not mattering is not an edge case in digital legacy. It is the central case, and planning that starts from it produces very different documents from planning that starts from a list of credentials in an envelope.

Custody, not encryption, is the legacy question

Most conversations about leaving digital information behind begin in the wrong place. They begin with encryption — how strong it is, which algorithm, whether the company can read your notes — as if the executor’s problem were a cryptography problem. It almost never is. Executors are rarely defeated by mathematics. They are defeated by custody: by not physically holding the thing that contains the information, in a form they are permitted and able to open, at the moment they need it. A perfectly encrypted vault that lives only inside someone else’s account, on someone else’s servers, behind someone else’s sign-in flow, is not an inheritance. It is a rumour of an inheritance. Sorting out legacy planning means separating three words that everyday speech cheerfully merges — custody, encryption, and access — and then designing for each of them on purpose.

Custody is the simplest of the three and the most often neglected. Custody asks: where does the data physically and legally sit, and who holds it right now? A notebook in a desk drawer is in your custody in the plainest sense. A file on a drive in your house is in your custody. A note inside a cloud account is in a more complicated position that families consistently misjudge: the company holds the servers, operates the software, sets the terms, and can change the interface, the export format, the retention policy, and the very existence of the product, while you hold a licence to use the service for as long as you comply and keep signing in. When people say my notes as if the phrase settled the matter, they are usually describing how the notes feel from inside the app. Custody describes how they look from outside it, on the day the account holder is no longer there to sign in.

Encryption asks a different question: if someone obtains the data, can they read it? Strong encryption renders a stolen file useless without the key, and that protection is genuine and worth having — data breaches, lost drives, and snooping are real risks during life, and a legacy store that any finder can read is a gift to identity thieves at the exact moment a family’s guard is down. But encryption says nothing about whether your executor can obtain the data in the first place, and nothing about whether they hold the key. A cloud note can be encrypted in transit and at rest by its provider and still be wholly inaccessible to your family, because the provider’s encryption is operated for the account holder, on the account holder’s successful sign-in. Conversely, a file can be entirely unencrypted and perfectly inheritable, because it sits on a drive in a labelled envelope. Neither fact makes the other unimportant. It means a legacy plan has to pass two independent tests — can my executor get hold of it, and can only my executor read it — and most improvised plans pass at most one.

Access is the third term, and the slipperiest, because access is not a property of a file. Access is an event: a particular person, at a particular time, successfully presenting whatever a particular system demands. Passwords, codes, trusted devices, recovery keys, death certificates, court orders — all of these are attempts to produce that event. Planning in terms of access explains why so many arrangements that look complete on paper fail in practice. The paper lists secrets. The event requires secrets plus devices plus timing plus a provider whose policies permit the attempt plus an account that has not yet been frozen, deleted, or flagged. Change any element and the event may not occur, even though nothing on the paper was wrong. Custody-based planning starts from the opposite end. Instead of rehearsing how an executor might persuade someone else’s system to let them in, it asks how the information can already be in the executor’s hands, or in a place the executor can lawfully take it from, before any persuasion is needed.

This is also where an uncomfortable legal reality needs to be stated carefully, because families routinely assume the opposite of what the law tends to do. This section is general information about how these arrangements typically work, not legal advice about any particular estate, and anyone settling a specific estate should take advice in their own jurisdiction. With that said: an account with a technology company is generally not property in the way a house or a bank balance is property. It is a permission — a contractual licence granted to one named person, on stated terms, usually non-transferable, which ends or transforms at death according to the contract and the applicable law. You can bequeath the laptop. You can bequeath the drive. Bequeathing the account is closer to bequeathing a gym membership or a library card: the sentiment is clear, the mechanism is not, because the other party to the contract never agreed to you as the counterparty. Executors who arrive at a provider speaking the language of ownership — this was his, therefore it is now ours — discover that the provider is speaking the language of contract and privacy law, in which their duty runs to the account holder and to the security of every other account holder, and in which a persuasive story is not a credential.

The statute most often relevant in the United States illustrates the point precisely, because it was written to give families a route in and still puts the company’s own tools first. The Revised Uniform Fiduciary Access to Digital Assets Act — RUFADAA, enacted in some form in most US states — establishes a priority order for instructions about digital assets. At the top sits a designation made through the provider’s own online tool, where the provider offers one: the setting inside the account where the user names who may have access, or what should happen, after death or incapacity. Below that come instructions in a will, trust, or power of attorney. Below that, the provider’s terms of service govern by default. Read that order again, because it reverses what most people expect. A carefully drafted will does not override the toggles inside the account. If a user once set an in-account tool to delete everything, or named a person they have since fallen out with, or never looked at the tool at all while their will speaks eloquently about digital wishes, the tool’s setting can take precedence over the will’s words. The practical consequence for planning is not to abandon wills — a will remains the right place for appointing fiduciaries and stating wishes where no tool exists — but to treat the in-account settings of major providers as part of the estate documents themselves: things to review, align, and record, in the same sitting, with the same care.

The major providers’ own tools also show how different custody and access look once a company designs for death deliberately. Apple’s Legacy Contact arrangement is instructive because it is explicit about its boundaries. A user designates a contact during life and generates an access key, which the contact must keep; after the death, the contact presents that access key together with a death certificate, and Apple grants access to a defined range of material — photos, messages, notes, files, and backups among them — for a period of three years from the first approval. Just as instructive is what the arrangement excludes: purchased media licences do not transfer, and the iCloud Keychain — the stored passwords, passkeys, and payment information — is not included. Even a well-designed, provider-sanctioned legacy tool, used exactly as intended, hands over the photographs and withholds the keys to everything else. And the key itself is unforgiving: if the contact loses the access key, Apple cannot replace it. The designation was the plan; the key was the plan’s single artefact; lose the artefact and the plan is a memory. Google’s Inactive Account Manager embodies a different philosophy built on the same custody insight. A user may name up to ten trusted contacts and choose an inactivity period of three, six, twelve, or eighteen months, after which Google shares selected data with those contacts as downloads. It never hands over passwords or the ability to sign in as the deceased. The contact receives copies of chosen material, not the account — a distinction Google maintains deliberately, and one that should shape what families expect: downloads of what was selected in advance, not a master key to what was not.

A will, finally, is exactly the wrong container for the secrets themselves, for a reason that has nothing to do with technology and everything to do with probate. In many jurisdictions a will, once admitted to probate, becomes a public record. Anyone who knows where to look may read it. A password written into a will is therefore not a private instruction to an executor; it is a secret scheduled for publication at the moment of maximum vulnerability, when accounts are known to be unattended and an estate is in transition. Families sometimes sense the risk and reach for euphemisms or separate codicils, but the structural problem remains: a document designed to be proved in public cannot double as a safe. Passwords do not belong in wills. Recovery keys do not belong in wills. What belongs in a will is the existence and location of the legacy store — the fact that one exists, where the physical artefact lives, and who is intended to open it — so that the public document points to the private vault without ever containing its contents.

Put together, these points reframe the task completely. The legacy question is not how to make an executor persuasive enough, documented enough, or patient enough to defeat sign-in systems designed to resist exactly them. The legacy question is how much of what matters can be moved, during life, out of permission-based accounts and into a store the testator actually holds — a store whose custody can be transferred as plainly as handing over an envelope, whose encryption protects it in the interval before the executor opens it, and whose opening requires no company’s cooperation, no live phone number, no trusted device, and no race against a deletion clock. Encryption still matters in that design. It simply stops being the whole design. Custody is the question; encryption is one of its safeguards; access, if the first two are handled well, becomes the unremarkable event of the right person opening the right file in their own time.

The three clocks running on every account

Death starts clocks that the bereaved cannot hear ticking. While a family is arranging a funeral, notifying relatives, and locating a will, the digital estate is already changing underneath them — not through malice, but through automation. Every account a person held is governed by timers that were set long before, for reasons that made sense at the time: to free up storage, to protect abandoned accounts from hijackers, to comply with policy, to recycle scarce resources like phone numbers. An executor who does not know the clocks exist will experience their effects as a series of baffling, apparently personal refusals. An executor who does know can prioritise, in the first days, the handful of actions that stop the fastest clocks — and a testator planning ahead can design a legacy store that none of these clocks can reach. There are three of them, and they run at very different speeds.

The first is the inactivity clock, and it is the most mechanical. Providers measure the time since an account was last used and act when that time crosses thresholds they have chosen. Microsoft’s published position gives a concrete sense of scale: Outlook.com and OneDrive accounts freeze after one year of inactivity and are deleted shortly afterwards, and Microsoft accounts more generally expire after two years of inactivity. A year sounds generous in the abstract. In the life of an estate it is not. Probate can be slow. A house can sit unsold while relatives negotiate. A disputed will or a missing document can stretch proceedings well past the point where a free email account, quietly unopened because nobody could open it, tips over from dormant to deleted — taking with it the password-reset route for half the other services in the estate, since email is the recovery backbone for nearly everything else. Google’s Inactive Account Manager is the same clock turned into a planning instrument: the user chooses in advance whether the trigger is three, six, twelve, or eighteen months of inactivity, and what happens when it fires. Notice, though, that even there the clock only distributes what was selected beforehand, as downloads to named contacts. It does not preserve the account, and it does not stop other providers’ clocks, which are running independently, on different schedules, in companies that do not consult one another about the estate’s timetable.

Inactivity clocks also run in miniature, at speeds families feel within weeks. A phone that stops being unlocked stops being a trusted device that recently checked in. A banking app that expects periodic confirmation treats silence as risk. Sessions expire. Devices that once sailed through sign-in begin, after a gap, to be challenged as if they were new. None of this requires a policy decision by anyone; it is the ordinary decay of the trust that continuous use maintains, like a path growing over once nobody walks it. The executor who finally obtains a device, weeks after the death, often finds that the device remembers less about its owner than it did on the day he died — not because anything was erased on purpose, but because trust, in these systems, is a perishable good with a short shelf life.

The second clock is the retention and deletion clock, which starts not from the last sign-in but from events the family itself may trigger: a notification of death, a request for memorialisation, a cancelled contract, a returned device. Here the timelines can be startlingly short and largely irreversible, because deletion is what these systems are optimised to do reliably. Cancel a mobile contract, as the helpful relative did in our opening scene, and the number’s association with the deceased ends immediately; the number itself enters a pool to be reclaimed and, after the network’s own interval, reassigned. Close an account at a family’s request and some providers treat closure as an instruction to purge within a fixed window, helpful staff following a script whose later steps cannot be recalled once executed. Return a leased phone or trade in a device as part of tidying the house, and whatever local copies, authenticator seeds, and signed-in sessions it carried leave the estate’s control in a cardboard box. Even without any family action, retention policies quietly thin the record: messages in some services are kept for defined periods, backups rotate and overwrite, temporary files vanish, and cloud photographs held in a recently deleted folder empty themselves on schedule. The retention clock’s cruellest property is that its actions often look, from the family’s side, like nothing happening. No letter arrives saying the number has been reassigned, the backup overwritten, the folder purged. The executor discovers each loss later, at the moment of need, as a door that was open in January and is simply, silently, not there in March.

Providers also differ sharply in whether a death notification opens anything at all, and the differences belong in any honest account of this clock. Microsoft’s general position is that it cannot give information about an account to non-account holders, and that access to an account’s contents requires a valid subpoena or court order — a legal instrument most families will never obtain for the purpose of finding out which streaming services their father subscribed to, and one whose cost and delay must be weighed against the estate’s actual needs. That is not an aberration. It is the retention clock’s companion principle: as time passes, the family’s practical routes narrow to the legal ones, and the legal ones were designed for disputes and investigations, not for household administration. Planning that assumes a provider will make an informal exception is planning that the providers’ own published policies contradict.

The third clock is the slowest, the least visible, and in some ways the saddest: the human memory clock. Long after servers have made their decisions, the estate depends on what living people can still recall, identify, and explain — and that, too, decays on a schedule nobody sets. In the first week, a spouse or child can look at a photograph and name everyone in it, say where it was taken, and explain why it matters. Five years later, clearing the same house for a move, the names have thinned to faces that look familiar. Photographs without context do not merely lose charm as memory fades; they lose identity, which for family purposes is most of their value. The same decay applies to the estate’s working knowledge. Who was the accountant? Which of these similar company names is the current insurer and which is the one he left in anger three years ago? What did this abbreviation in his notes mean — a project, a person, a place? In the early days, several relatives each hold fragments and can still assemble them. As months pass, people move, change numbers, fall ill, and die themselves, and the fragments scatter. A note that says only the usual arrangement for the house is a complete instruction in the month it is written and a riddle within a few years.

The memory clock also governs identifiers, the unglamorous labels that make digital material findable. A folder named by a project nickname means everything to the team that used the nickname and nothing to the executor searching for a tax document. A drive labelled with initials, a backup dated by a system the family does not recognise, a set of files whose naming convention lived entirely in the deceased’s head — each is a small lock whose key is a memory. Devices accelerate the loss in their own way. A computer that is not maintained stops receiving the updates that keep its software able to open newer formats and sign in to current services. A phone left in a drawer discharges, and some devices, left flat for very long periods, become reluctant or fail to return. Trusted check-ins stop because the household’s network changes: the router is replaced during a provider switch, the Wi-Fi name the laptop knew disappears, and a machine that was once woven into a home’s digital fabric wakes, if it wakes, as a stranger in its own house.

Seeing the three clocks together changes what good planning looks like. Against the inactivity clock, the answer is not to beg an executor to sign in periodically to accounts they may have no right to operate; it is to make the essential record independent of any account’s activity. Against the deletion clock, the answer is to place copies where no provider’s retention policy runs — because a policy, however reasonable, is a decision a company will go on executing faithfully long after it has forgotten the reason a particular family needed an exception. Against the memory clock, the answer is to write the context down while the writer still holds it: names in full, relationships, what a folder contains and why it was kept, which insurer is current, what the abbreviation means. A legacy note that carries its own context defeats the third clock in a way no password ever could, because passwords authenticate a person and context instructs a stranger — and an executor, however beloved, is partly a stranger to the inside of someone else’s filing system. The testator who understands the clocks stops asking how long an executor will have. They start asking a better question: what can I finish, copy, label, and place in safe custody now, while all three clocks are still, for me, standing still?

What a death certificate can and cannot do

Few documents are surrounded by as much misplaced confidence as the death certificate. Families obtain certified copies — often several, on advice, at some expense — and carry them into interactions with banks, insurers, and technology companies with the reasonable expectation that an official document, recording an official fact, will function as a master key. It does perform real work, and the final part of this opening section will be precise about what that work is. But its power is specific, and misunderstanding its specificity sends executors down corridors that were never going to open, burning the scarcest resource an estate has in its first weeks, which is not money. It is time inside the windows the three clocks allow.

What a death certificate proves, it proves well. It establishes, to the standard institutions require, that the named person has died, on a recorded date, in a recorded place. Presented to a provider, it satisfies the factual precondition for almost every bereavement process that provider operates. It supports an executor’s standing when paired with the documents that appoint them. It allows accounts that are designed to close on death to be closed properly rather than abandoned. It is the document Apple’s Legacy Contact process asks for alongside the access key, and in that pairing its correct role is visible at a glance: the certificate proves the death, the key proves the entitlement, and neither document substitutes for the other. A certificate without the key leaves Apple — on its own published terms — able to acknowledge the death and unable to grant the access, with no power to mint a replacement key for a family that has lost it. Families who keep only one of the pair have kept the half that proves a fact the company was never really doubting.

What providers typically do in response to that proof surprises people, because the response is usually a form of locking rather than unlocking. A company notified of a death acts, first, to protect the account from the risks that cluster around deaths: fraud by acquaintances who know the answers to security questions, opportunistic transfers, well-meaning relatives guessing at credentials. Freezing an account, closing it, memorialising a profile, or terminating services are, from the provider’s side, the responsible moves, and several of them are functionally one-way. The executor who writes to a company early, certificate enclosed, hoping to begin a conversation about access, may instead begin a countdown to closure they did not intend — which is why experienced practitioners are deliberate about sequence: identify what must be preserved or exported, understand each provider’s stated process, and only then notify in the order that loses the least. None of that deliberation is possible if the family’s essential information lives exclusively inside the accounts being notified about. It is entirely possible if the essential information lives in a legacy store the executor already holds, because then each notification becomes an administrative act performed from a position of knowledge, rather than a gamble taken in the dark.

The deeper misunderstanding is the equation of legal authority with technical access. An executor’s authority is real. It derives from a will and a grant from a court, and it empowers them to act for the estate in ways the law recognises: to collect assets, pay debts, and distribute what remains. But a grant of probate is an instruction to people and institutions within the law’s reach. It is not a credential. It does not change what a zero-knowledge vault can be made to reveal, because there is nothing in the provider’s possession to reveal; it does not regenerate a lost recovery key, because the key was generated to be unregenerable; it does not compel a phone to forget its passcode, because the passcode’s protection does not contain a probate exception. Where providers do offer a legal route to content, they describe it in legal terms — Microsoft’s requirement of a valid subpoena or court order for account contents being the clear example — and that route, even when successful, is measured in legal time and legal money, aimed at a defined evidentiary need. An executor who needs to know whether the house insurance is current this Friday is not served by a process that may conclude next season. The gap is not a failure of the law or of the technology, taken separately. It is the seam between them, and estates fall into it precisely when nobody planned for the seam in advance.

Consider, against that background, what an executor’s job actually is in the first two weeks, because the contrast between its true content and its popular image explains the urgency of everything argued so far. The popular image involves reading a will, valuing heirlooms, and meeting a solicitor. The true content is a triage list of living obligations that do not pause for mourning. Utility accounts must be identified so a house is neither left uninsured and unheated nor billed into arrears. Insurance — buildings, contents, vehicle, life — must be located, checked for the notification deadlines many policies impose after a death or a change in occupancy, and kept valid while the property stands empty. Direct debits and recurring card payments must be inventoried, because some represent essential cover that must continue and others represent services that should stop before they consume the estate, and from outside the accounts the two kinds look identical until investigated. Domains, if the deceased held any — a family email domain, a small business site, a name registered years ago and quietly central to how relatives sign in to other services — sit on renewal cycles that do not care about probate, and a lapsed domain can break email delivery for a whole household in a single night. Subscriptions must be found not mainly to save their cost, but because the pattern of subscriptions is often the most complete map of the deceased’s digital life that exists: storage plans hint at where photographs live, software renewals hint at which computer mattered, delivery services hint at accounts holding order histories and stored payment methods. Tax records, pension correspondence, medical billing, a landlord or a mortgage servicer — the first fortnight is an exercise in establishing, from fragments, the full list of relationships a household must now manage in one person’s name only.

Now hold that list against the obstacles the earlier sections described, and the blockages align with depressing neatness. The inventory of direct debits requires either bank access, which has its own appointment and identity processes, or the deceased’s own notes, which are the thing in question. The insurance details are in an email account whose sign-in wants a code from a cancelled number. The domain renews through a registrar account protected by an authenticator on a locked phone. The subscriptions announce themselves only as they charge, one by one, on a card the family is simultaneously being advised to stop. Every item on the triage list is answerable in principle and obstructed in practice by the same root cause: the knowledge of what exists was stored inside the systems that the knowledge was needed to operate. That circularity — not any single company’s policy, not any single missing password — is the enemy. Breaking it does not require the executor to become a technician or the testator to become a lawyer. It requires one store, outside the circle, holding the map: what the accounts are, who provides them, when they renew, what should continue and what should stop, where the important records live, and how the executor is to open the store itself. The map is not the territory, and a good legacy vault does not pretend to be a set of working keys to every service. It is something more valuable in the first two weeks than any key: a true list, readable on demand, that turns triage from archaeology into administration.

That is also the standard against which the rest of this article should be judged. Every mechanism examined from here on — how a local, encrypted vault is built, what belongs in it and what must be left out, how its passphrase and its physical copies are entrusted, how providers’ own legacy tools are set alongside it rather than instead of it — earns its place only insofar as it serves an executor standing in a kitchen in the first fortnight, certificate in one hand, facing a sign-in screen that does not accept certificates. The certificate will still be needed; the solicitor will still be needed; the providers will still have to be written to, in the right order, with the right documents. Nothing in a well-made vault abolishes the formal work of death. What it abolishes is the helplessness that comes from doing that work blind. A parent cannot leave their family exemption from paperwork. They can leave them the map, in a form the family actually holds, protected strongly enough to be safe and simply enough to be opened by the person it was made for. Building that map — its contents, its custody, and its keys — is where this article turns next.

What happens to your notes on each platform after you die

The most useful question you can ask about any notes app is not how it behaves while you are alive and logged in. It is how it behaves on the worst week your family will ever have with it: when you cannot unlock a phone, cannot answer a recovery email, and cannot explain which of the forty similarly titled notes actually matters. Every major platform answers that question differently, and the differences are not cosmetic. Some have built a deliberate doorway for a named person after death. Some have built a timer. Some have built, in effect, a wall, and tell you in their own documentation to make your own arrangements outside the product. If your legacy plan consists of a sentence like “everything is in my notes,” the platform underneath those notes decides whether that sentence is a plan at all.

Read the five accounts below as five different legal and technical machines. What your executor receives, what is permanently excluded even from a successful claim, and how long the whole process takes are separate questions, and a platform can be generous on one and unforgiving on another. A service can hand over your notes promptly and still withhold every password needed to act on them. A service can preserve an account for years and still give your family no lawful way inside it. A service can offer a thoughtful legacy feature and still make one lost piece of paper — an access key stored in the wrong place — fatal to the entire arrangement. This is why a legacy vault has to be designed around the platforms, not simply stored inside one of them.

Apple Notes and iCloud

Apple is the clearest case of a company that has built a specific mechanism and defined its boundaries precisely. The mechanism is Legacy Contact. While alive, the account holder designates a trusted person, and that person receives an access key. After the account holder’s death, the legacy contact presents two things to Apple: that access key, and a death certificate. Both halves are required. The key proves the designation was made deliberately by the account holder; the certificate proves the triggering event has occurred. Neither half on its own opens anything.

When Apple approves the request, the scope is broad in the ways that matter most for notes and family records. The legacy contact can access photos, messages, notes, files, and backups stored in the account. For a family trying to reconstruct a household — the photograph of a document, the note listing a safe combination’s location, the message thread that explains a family decision — that breadth is genuinely valuable. Apple Notes, in this model, does not die locked inside the phone. It becomes part of an estate that a named person can actually read.

The exclusions, however, are exactly the exclusions an executor feels first. Purchased movies, music, books, and subscriptions do not transfer through this route. More consequentially, iCloud Keychain data is excluded: payment information, passwords, and passkeys stay out of reach. That means a legacy contact may be able to read a note that says an account exists, and still have no credential with which to sign in to that account. They may see the map without receiving the keys. For many families that distinction arrives as a shock, because in everyday life Notes and Keychain feel like parts of one phone, one account, one person. After death Apple treats them as different categories with different rules, and only one category walks through the legacy door.

The clock matters as much as the scope. Access lasts for three years from the first approval, and then the account is deleted. Three years is not short — it is longer than most estates take to administer — but it is a deadline with a hard end, and it starts when the first approval happens, not when the family feels ready. Anything the family wants to keep beyond that window has to be copied out deliberately during it. Photographs left unexported, notes never saved elsewhere, files assumed to be “in the account” in some permanent sense — all of them disappear when the period closes. A legacy contact who treats those three years as storage rather than as a transfer window can lose the material at the end of a process that otherwise worked exactly as designed.

The most fragile point in Apple’s design is the access key itself. Apple cannot access or replace a lost access key. That is a defensible security choice: a key the company could reissue would be a key its support staff could be persuaded to reissue to the wrong person. But it transfers a very concrete responsibility to the account holder. Where the key is kept, who knows where it is kept, and whether a second copy exists somewhere the legacy contact can reach without already having access to the account — these are not administrative details. They are the plan. A designation made in Settings, followed by a key saved only inside the same account it unlocks, is a circular arrangement that fails in precisely the situation it was built for. Families discover this only at the moment of use, when there is no account holder left to generate a new key and no support route that can substitute for one.

So Apple’s answer, stated plainly, is this: a named person can get the notes, the photos, the messages, the files, and the backups, with a key and a death certificate; they cannot get the purchased media, the subscriptions, or the Keychain credentials; they have three years from the first approval to take what they need; and if the key is lost, the company’s inability to replace it is not a support failure to be escalated but a stated limit of the system.

Google Keep and the Google account

Google Keep does not have a separate after-death existence of its own. Your Keep notes live inside your Google account, so Keep inherits the fate of that account in full. That inheritance runs through a feature with a different philosophy from Apple’s: Google’s Inactive Account Manager is not triggered by a death certificate presented by a family member. It is triggered by inactivity — by the account going silent for a period its owner chose in advance.

While alive, the account holder can name up to ten contacts and select an inactivity period of 3, 6, 12, or 18 months. When that period of silence elapses, the named contacts can be given access, and the owner decides in advance, contact by contact, which categories of data each person may download. That granularity is the strongest part of Google’s design. A spouse might receive everything, a business partner only a defined slice, a sibling only the photographs or the notes relevant to them. The data arrives as downloads chosen ahead of time, rather than as open-ended browsing of a living account. For a person who kept very different parts of life inside one Google account, the ability to separate audiences before the fact is a real protection for everyone’s privacy, including the deceased’s.

Keep notes, under this arrangement, are only as reachable as the account category they sit inside and the contact selection their owner made. A contact who was never selected for the relevant data receives nothing through this route, however close the family relationship. A contact who was selected receives a download, not the account itself. And there is one boundary Google states without ambiguity: Google will not hand over passwords. As with Apple, the map and the credentials are different things. A downloaded note can tell an executor that a storage unit, a domain, or a tax account exists. It cannot sign the executor in. Any plan that silently assumes “Google will give them my passwords” is built on a premise the company has already ruled out.

The timeline contains a trap for the unprepared, because the chosen inactivity period and a separate deletion horizon run at the same time. A family may know, privately, that a person has died, while Google’s systems know only that an account has gone quiet. If the owner selected a long inactivity period, the contacts wait that long for the planned release. If the owner never set up Inactive Account Manager at all, there is no release plan to wait for — and Google may delete an account that has been inactive for two years. Two years sounds distant when a person is healthy and setting up a phone. Measured from a sudden death followed by a contested estate, a house that cannot be sold quickly, or a family that simply does not know which accounts exist, it is not distant at all. Accounts can be forgotten for longer than that by people who are actively trying.

There is a second, quieter consequence of Keep’s position inside the wider account. Keep is where many people keep exactly the material an executor needs first: the note with the gate code’s location, the list of medications, the account inventory drafted at midnight, the instructions for the dog, the combination hints, the names of the lawyer and the accountant. Because Keep is quick and frictionless, it attracts precisely the notes that feel too informal for a document and too important to lose. Those notes then sit inside a system whose release depends on an inactivity timer configured — or never configured — in a settings page most users have never opened. The informality of the tool and the formality of its after-death process are badly matched, and closing that gap is the account holder’s job while they are still able to do it.

Google’s answer, then: plan ahead and up to ten chosen people can receive chosen categories of your data as downloads after 3, 6, 12, or 18 months of inactivity, depending on what you selected; passwords are never part of the handover; and with no plan in place, an account inactive for two years may be deleted, taking every Keep note inside it with it.

Microsoft OneNote and OneDrive

Microsoft’s position is the starkest of the five, and it is worth reading carefully because so many households keep their real records — the scanned deeds, the insurance PDFs, the family spreadsheet, the OneNote notebook that has accreted a decade of household knowledge — inside OneDrive and OneNote without ever asking what a non-account holder can obtain. According to Microsoft’s own support guidance, the company is generally unable to provide information to non-account holders. That sentence, not any technical limitation, is the centre of the policy. The account belongs to the account holder, and Microsoft does not operate a self-serve legacy designation equivalent to Apple’s or Google’s arrangements that a family can simply invoke.

If nobody knows the credentials, the account’s end is governed by inactivity rather than by a family’s needs. The account closes automatically after two years of inactivity. The services inside it run on shorter clocks of their own: Outlook.com and OneDrive are frozen after one year of inactivity, and messages and files are deleted shortly after that freeze. Note the sequence, because families routinely get it backwards. They imagine the two-year account closure as the deadline for everything, when in practice the contents they most want — the email that explains an arrangement, the OneDrive folder holding the scanned documents — can be frozen at one year and deleted shortly afterwards, while the empty shell of the account still formally exists. An executor who spends the first year on probate, property, and immediate family needs, planning to “deal with the Microsoft account later,” may return to find that later was scheduled by the provider, not by the estate.

For a family that needs access to content and does not have the credentials, Microsoft’s stated route is a legal one: access requires a valid subpoena or court order, formally served. That is not a support ticket, not a death certificate uploaded to a web form, and not a phone call in which a sympathetic agent makes an exception. It is a court process, with the cost, delay, and jurisdictional friction that court processes involve, and it is presumably designed that way: a company holding the private documents of millions of people does not improvise exceptions at a service desk. But the practical consequence for an ordinary executor is severe. Material kept only in OneNote may be, for the family’s purposes, functionally unreachable unless the credentials were passed on outside Microsoft’s system altogether, or unless the estate is prepared to litigate for it.

This is also where the difference between a notebook and a vault becomes concrete. OneNote notebooks synced to OneDrive are, from the family’s perspective after a death, provider-held content behind a provider-controlled door with no legacy keyhole. Whatever is in them is preserved or deleted on the provider’s inactivity schedule, and released, if at all, through the provider’s legal process. None of that makes OneNote a bad notebook while its owner is alive. It makes it a dangerous sole location for the instructions an executor needs in the first month, because the first month is exactly when the family has the least capacity to begin a court-order process for a notebook.

Microsoft’s answer, in short: no self-serve legacy designation, generally no information to non-account holders, content frozen at one year and deleted shortly after, the account itself closing after two years of inactivity, and a formally served subpoena or court order as the stated route to content. Of the five platforms here, this is the one where storing the only copy of your executor’s instructions inside the product is hardest to defend.

Evernote

Evernote’s terms approach death from the direction of a promise kept to the user, and the promise cuts both ways. The company’s privacy pledge continues after a user’s death or incapacity. In practice that means Evernote will not provide a user’s content to anyone — even next of kin — unless it determines that it is legally obligated to do so. The family relationship that feels, morally, like the strongest possible claim is explicitly not, by itself, a key. A spouse, an adult child, or an executor standing at a support channel with a death certificate and a reasonable request meets a policy designed to refuse exactly that request unless the law compels a different answer.

To its credit, Evernote does not pretend otherwise, and it does not leave the implication unstated. Its terms tell users to implement their own process for access after death, and encourage them to place access instructions in a will or estate plans. Read that as the product speaking honestly about its own limits: the notebook is private, the company intends to keep it private after you cannot speak for yourself, and therefore the bridge between your notebook and your executor has to be built by you, outside Evernote, while you are alive. The company has essentially announced that the legacy layer is not its job. That candour is more useful than a vague assurance would be, but only to users who encounter it before they need it.

There is one administrative opening, and its narrowness is instructive. An authorised legal representative can request cancellation of a paid subscription, with proof of authority. Notice what that request is and is not. It stops billing. It does not deliver notebooks. The estate can close the commercial relationship — can stop paying for a service nobody can enter — through a documented legal route, while the content itself remains behind the privacy pledge. A family can find itself in the strange position of formally cancelling a product whose contents it has never seen and cannot retrieve, which is a tidy illustration of how completely access and ownership separate after death on a platform with this model.

The timeline question, for Evernote, is therefore different in kind. There is no published legacy window counting down in the manner of Apple’s three years, and no inactivity release of the Google kind to wait for. The relevant timeline is the user’s own: whatever process the user built — instructions in estate plans, credentials shared through some other channel, exports made and kept somewhere reachable — operates on the estate’s schedule, and Evernote’s content operates on none of it. Notebooks that were never exported and never covered by a user-built process simply remain where they were, private in the fullest sense, as the estate closes around them.

Evernote’s answer: your privacy pledge survives you, your content will not be handed to next of kin without a legal obligation, you are told to build your own process and put access instructions in your will or estate plans, and a legal representative’s documented power extends to cancelling the subscription rather than opening the notebooks.

Notion

Notion requires the most careful wording of the five, because the honest statement is about an absence. Notion has no built-in legacy-contact or inactive-account designation of its own. There is no Notion equivalent of naming a legacy contact inside the product and generating a key for them, and no inactive-account manager in which you pre-select who downloads what after a chosen period of silence. A workspace that contains a family’s entire operating system — the household wiki, the property pages, the databases of documents and contacts and renewal dates — sits inside an account with no product-level bridge built for the owner’s death.

What families face instead are the general routes: account login, where the credentials are known and can lawfully be used; the company’s support channels, where identity, authority, and the specifics of the request are worked through case by case; and legal routes, where an estate’s representative pursues access through formal process. None of those routes is a promise of a particular outcome on a particular timetable, and that uncertainty is itself the planning fact. An executor cannot schedule around a route whose duration depends on correspondence and legal advice. They cannot assume that a page the family knows exists — because they saw it over the owner’s shoulder, or because it was once shared as a link — will be reachable in full, with its databases, attachments, and history, at the moment it is needed.

Shared pages deserve a specific warning here, because they create a convincing illusion of access. During the owner’s life, a Notion page shared with a spouse or a child feels like a copy safely in family hands. It is not a copy. It is a view into an account the family does not control, and views can narrow or end when the account behind them changes state. The underlying material — the full workspace, the unshared pages, the databases the shared page draws from — remains on the account side of the line. Families who believe “we can already see the important page” often discover that what they could see was a window, and the house was never theirs to enter.

The planning consequence is not that Notion should be avoided; for living collaboration it is frequently the strongest tool in this entire comparison, and this article will say so again later without hedging. The consequence is narrower and more actionable: anything in Notion that an executor will definitely need should also exist somewhere the executor can definitely reach. Export the critical pages. Keep the index of what lives in the workspace somewhere outside it. Treat Notion as the place where the living household does its work, and the legacy vault as the place where the record of that work survives the account holder. Those are different jobs, and only one of them has a built-in answer to the account holder’s death.

Notion’s answer, then, is that there is no designed answer inside the product: no legacy contact, no inactive-account designation, and a family left to the account-login, support, and legal routes, with all the uncertainty about scope and timing that those routes carry.

Step back from the five and a pattern emerges that matters more than any single policy. Two platforms built a door and defined who may walk through it, what they may carry, and when it closes. One built a timer and a download. One built a wall with a courtroom gate. One built, for this purpose, nothing at all. None of them — not one — hands over the full set of credentials an executor needs to run a household’s affairs, and two of them say so explicitly. Every route depends on something the account holder did, or failed to do, while alive: a designation made, a key preserved, a timer configured, a process written into estate plans. The platforms have already decided how much of this problem is yours. The rest of this article is about doing your part of it well.

This month proved the custody point again: the DreamHost breach

Custody arguments can sound abstract right up until a specific incident gives them an address, a date range, and a list of what was taken. This month supplied one. In reporting posted at 12:36 PM PST on November 4, 2026, TechCrunch described a breach at the web host DreamHost in which hackers exploited a vulnerability in the company’s web-based File Manager. Between August 2026 and October 23, 2026, the attackers could access the FTP and SFTP usernames and passwords of customers who used that File Manager, along with the session credentials of some webmail users. DreamHost’s breach notice said that email contents and files stored on the FTP and SFTP server may also have been accessed.

Pause on the shape of that exposure, because it is the shape that matters for legacy planning. The compromised material was not a stray marketing database. It was the combination an intruder dreams about: credentials that open servers, session material that opens inboxes, and then, behind those doors, the files and the email contents themselves. A person’s hosted files and hosted mail are where modern life keeps its records — the scanned documents uploaded to a website’s file area, the correspondence with the accountant and the insurer, the attachments that were never saved anywhere else. An attacker who reaches that layer does not need to guess what a family owns or whom it banks with. The records explain it.

The rest of the incident follows a pattern that should be familiar by now, and its familiarity is part of the point. DreamHost disclosed the breach the previous Thursday, after a multi-day outage during which it reset some customer passwords. A spokesperson said the affected customers were well under 10% of the company’s roughly 400,000 paying customers. A data breach notice was filed with California’s attorney general. Each of those facts is reasonable in isolation — disclosure, containment through password resets, a proportion, a regulatory filing — and each of them also demonstrates how completely the customer’s position depends on the provider’s systems, the provider’s timetable, and the provider’s incident. The password reset deserves particular attention from anyone building an estate plan on hosted access. Resetting passwords is a correct defensive move. It also means that the credential an executor was given, carefully written down and stored for exactly this emergency, can be invalidated by the provider in the middle of the emergency — not through any fault of the family’s, but because the provider was protecting the account from someone else.

Now place a legacy plan inside that picture. Suppose the executor’s instructions live only in a hosted inbox: the email from the deceased explaining where the will is kept, the message with the accountant’s details, the thread that lists the insurance policies. Suppose the family archive lives only as files on a hosted server, reachable through a file manager or an FTP login. Suppose the master inventory — the single document that maps the domains, the hosting accounts, the registrar, the properties, the policies — exists only in one of those two places. That plan has inherited, wholesale, the exposure described above. The most sensitive map a family possesses sits on someone else’s server, behind someone else’s vulnerability, reachable with credentials that someone else’s breach can spill and someone else’s incident response can reset. The family did nothing careless by the ordinary standards of digital life. They used email and hosted files the way everyone uses them. The carelessness only becomes visible when you ask the legacy question: what, exactly, stands between a stranger and this map, and who controls it?

A VaultBook legacy vault is built to give a different answer to that question. It is a single local file. It was never uploaded to a file manager, never attached to a hosting account, never placed on an FTP or SFTP server for the convenience of reaching it from another machine. In an incident like the DreamHost breach, there was therefore nothing of the vault’s on that server to steal — no vault file in the exposed storage, no vault contents in the exposed inboxes, no vault credential among the spilled FTP passwords. And the second half of the incident cuts the other way as well: no provider password reset could lock an executor out of the vault, because the vault does not depend on a provider account at all. Its door is its own passphrase, applied to its own encryption, on a file the family physically holds. A hosting company’s bad quarter — a vulnerability window running from August into late October — simply does not reach it.

Honesty requires the limit to be stated in the same breath, and it is stated again elsewhere in this article because it cannot be said too plainly: the vault still depends on the owner sharing its passphrase properly. A local encrypted file whose passphrase was never passed on is not a legacy plan; it is a very secure way to lose information permanently. The DreamHost incident argues for custody — for keeping the family’s map out of other people’s breach radii — not for the fantasy that encryption alone completes an estate plan. Custody decides whose failures can hurt you. The passphrase handover decides whether your own plan works at all. A serious legacy arrangement gets both halves right, and the sections that follow are about the second half as much as the first.

There is also a quieter lesson in the incident’s duration. The access window ran for months before it closed on October 23, and the public disclosure came later still. Hosted exposure is not a moment; it is a period during which copies can be made at leisure, and a family may learn that its records were reachable long after the reachable period ended. A local file has no equivalent window. It is exposed when someone obtains the file and the passphrase, and not before — a risk the owner can see, count, and manage with physical decisions about where copies live. That visibility is, in the end, the custody argument in one sentence: with a local vault, the list of things that must go wrong for your family’s map to leak is a list you wrote; with hosted storage, it includes entries written by a provider’s attackers, on a schedule you will read about afterwards in the news.

What belongs in a legacy vault — and what never does

A legacy vault fails in two opposite ways, and most real attempts manage one of them. The first failure is emptiness dressed as tidiness: a vault containing a heartfelt letter and almost nothing an executor can act on, assembled by someone who confused the emotional document with the operational one. The second failure is dangerous completeness: a vault, or worse a binder, into which its owner poured every live credential they possessed, in plaintext, in one place, so that whoever finds the container — executor, burglar, curious houseguest — finds the whole estate at once. Building well means steering between those failures with a clear principle for what the vault is. The principle is this: the vault is the map, the index, and the instructions. Credentials have their own channels, their own protections, and their own rules, and only some of them belong inside the map at all.

Begin with what belongs. The first category is the account inventory: the names of accounts and what each is for. Every financial account, utility, insurer, platform, subscription, and service that touches the household’s money or records should appear, identified by institution and purpose. Note carefully what this category is: a statement that an account exists, where it is held, and what it does. For many accounts that statement is all an executor needs to begin, because executors do not usually sign in as the deceased — they present their authority to the institution and work through the institution’s own process. The inventory turns an unknown unknown into a known task. Without it, accounts are discovered by accident, by stray mail, by a charge on a statement, or not at all.

The second category is location information for originals. Much of an estate still turns on physical and authoritative originals: the signed will, property deeds, vehicle titles, insurance policies, certificates, the contents of a safe-deposit box. The vault should say where each original lives — which institution, which box, which filing cabinet, whose office — with the precision you would want if you were searching a house you did not arrange, under time pressure, while grieving. Copies and scans can sit in the vault as working references where that is useful, and VaultBook’s attachment handling and search make those references genuinely findable, but the entry’s essential job is to point at the authoritative thing and say where it is.

Third, the infrastructure of an online life: domain and registrar details, and hosting details. List every domain the person or the family owns, the registrar holding it, the account it sits in, and what depends on it — the family email, a business site, a portfolio, a redirect that other services rely on. List hosting in the same way: provider, what is hosted, and what would break if the hosting lapsed. Domains and hosting are the accounts most likely to be missed entirely by an executor, because nothing physical ever arrives in the post to announce them, and their loss is often irreversible in practice: a lapsed domain can be gone, with the email addresses under it, before a slow estate notices it existed.

Fourth, insurance and property documents deserve their own deliberate treatment rather than a line in a general list. For each policy — home, auto, life, health, umbrella, business — record the insurer, the type of cover, and where the policy document itself lives. For each property, record what it is, where its deed and records are, and the services tied to it. These are the documents an executor or a surviving spouse may need within days, not months: a claim after the same event that caused the death, a question about cover for an empty house, a lender asking for evidence of insurance. The vault’s job is to make the first phone call possible, with the right institution and the right reference in hand.

Fifth, instructions and wishes. This is the category people imagine first, and it matters — but it should be written as instructions, with the practical specificity that word implies. Who should be contacted, and in what order. What the person wants done with accounts, devices, archives, and ongoing projects. Where the preferences sit that have no legal instrument behind them but enormous family weight: the disposition of photographs, writings, collections, and the thousand small decisions an estate forces on people who would rather be mourning than deciding. Alongside the wishes, keep the key contacts as their own structured category — the attorney, the accountant, the financial adviser, the insurance agent, the property manager, the closest collaborators — with names, firms, and how to reach them. An executor’s first week is largely a sequence of phone calls, and a vault that makes those calls obvious has done more real work than one that merely stores files elegantly.

Finally, the family archive index. Few households have their photographs, letters, recordings, and documents in one place; almost all have them scattered across drives, phones, cloud accounts, boxes, and relatives’ houses. The vault does not need to contain the archive. It needs to index it: what exists, where it is, in what format, and under whose custody. That index is what turns a bereaved family’s vague knowledge that “there are photos somewhere” into a recoverable collection, and it is the only defence against the quiet losses — the drive nobody knew about, wiped in a house clearance; the account nobody listed, deleted on an inactivity schedule while the family mourned.

Now the other side of the line, taken just as seriously. Some things never belong in the vault, and the first is the most commonly advised mistake in all of legacy planning: passwords written into a will. A will becomes a public record through probate. Anything written in it — including, disastrously, a master password or a list of credentials — enters a document that strangers may lawfully read. The will is the right place for instructions about who receives what and who holds authority. It is exactly the wrong place for secrets, because its legal function requires it to stop being private. Keep credentials out of it entirely, without exception, however convenient the single-document idea feels.

The second exclusion is the plaintext password list, wherever it is proposed to live. A single unencrypted document, spreadsheet, or notebook page listing live passwords concentrates the entire estate’s access into an object with no protection of its own. Photographed once, copied once, found once, it is everything. This is not a theoretical scruple. It is the precise weakness that emergency-binder discussions among real users circle again and again: a binder that brings order to a household’s chaos is valuable, but a binder that also prints the master password hands a thief the whole system in one grab, because the binder itself is exactly the object a burglar or a dishonest visitor would take. The vault exists to break that pattern — information organised in one place, protected by encryption rather than by the obscurity of a drawer.

The third exclusion is subtler: copies of things whose only copy should stay inside an institution’s own process. Some documents and credentials derive their force from being the authoritative original held through a bank’s, a court’s, or a registry’s procedure, and duplicating them into a home vault adds risk without adding power. The vault should point to those things — record that they exist, where the process lives, and whom to approach — rather than hoard copies that could be mistaken for the real instrument or leaked in place of it. The map is not diminished by refusing to be the territory. It is what makes the map safe to keep and safe to share with the people who need it.

Underneath all three exclusions sits one distinction worth stating as a rule of thumb, because it resolves most borderline decisions on its own. Ask of any item: is this the map, or is this a key? Maps belong in the vault. Keys belong in the channel designed for keys — a password manager’s own sharing and emergency mechanisms, a sealed envelope held by a named person, an attorney’s custody — with the vault recording the fact of the arrangement and the location of the key, not the key’s teeth. An inventory that names every account while keeping most live passwords in their proper channel gives an executor everything needed to start every process, while ensuring that a single compromised container does not equal a compromised estate.

That separation leads directly to the design that experienced planners converge on, and that Reddit’s emergency-binder and digital-estate discussions return to from many directions: split knowledge. The map lives in the vault. The vault’s passphrase is held separately, by the executor or the attorney, in a different place from the vault file itself. Concretely, people describe keeping a copy of the vault on a USB drive stored in one location, and the master password in a sealed envelope in another — with a solicitor, in a safe-deposit box, with the named executor — precisely so that no single theft, fire, or curious discovery assembles the whole. The sealed envelope can even be tamper-evident, so its owner would know if the secret had been disturbed. And the same discussions surface the failure mode that split knowledge exists to prevent, from the other direction: a vault whose own access password is stored only inside itself is a circular trap, a safe whose combination is locked in the safe. Every design decision in this area is, at bottom, an attempt to avoid those two shapes — everything in one grabbable place, or everything sealed behind a door whose only key is behind the same door. Split the map from the key, write down where each half lives and who holds it, and tell the holders they are holders. That sentence, acted on, is most of a working legacy plan.

The inventory your executor actually needs

An inventory is not a pile of facts. It is a work list written for a specific person who will arrive with legal authority, limited knowledge of your arrangements, and a limited supply of calm. The test for every category below is the same: could a competent stranger, given this entry and nothing else, take the first correct step within one working day? If the entry names an institution but not the purpose of the account, it fails. If it describes a document but not where the original sits, it fails. If it lists a device but gives no route to its passcode’s whereabouts, it fails in the modern way — completely, and with the data visible behind glass. Work through the categories in order, write each one to that standard, and resist the temptation to treat any of them as obvious. Nothing is obvious to the person who did not build the system, and the builder is the one person guaranteed not to be present.

Money

Start where the estate starts. List every bank account, savings account, and credit union relationship: the institution, the type of account, its purpose in the household, and whether it receives income or pays anything automatically. Add investment and retirement accounts in the same form, naming the firm and the kind of account, and note where statements and tax documents for each can be found. Record debts with equal care — mortgage, vehicle finance, credit cards, personal loans, any private arrangement with a friend or relative — because an executor who discovers a debt late has usually discovered it expensively, through a missed payment or a collections letter. Include the payment rails themselves: which account the mortgage leaves, which account the utilities draw on, which card the household’s subscriptions charge. In the first month after a death, accounts may be frozen, notifications may lag, and the difference between a household that keeps functioning and one that cascades into missed payments is often nothing more than this single page of knowledge about which account feeds which obligation.

What does “done” look like for money? Every institution the person banked, saved, invested, borrowed, or paid through appears, with its purpose stated in plain words; the automatic movements of money in and out are traced to their source accounts; and any account that exists for a single narrow reason — the account only the taxes touch, the card only the travel touches — says so, because narrow accounts are the ones families close by accident or overlook entirely. If the executor can sit down with this section and a death certificate and open the correct conversation with every institution in a single day of calls, the section is done. If they have to guess whether an account is missing, it is not.

Home

The home category covers the property itself and everything that keeps it running. For the property: its address, where the deed lives, the mortgage holder if there is one, the insurer, and the property tax position. Then the services, one by one — electricity, gas, water, internet, any alarm or monitoring arrangement, any maintenance contract, any cleaner, gardener, or tradesperson with standing access or a standing arrangement. Add the physical keys to power: where spare keys live, who else holds one, the alarm code’s whereabouts, the location of the water shutoff and the breaker panel if they are anywhere non-obvious, and any smart-home accounts that control locks, heating, or cameras. A house whose executor cannot stop a leak, silence an alarm, or let in a plumber is not a colourful anecdote; it is a source of real damage in the gap between a death and an estate taking control.

Done, for the home, means the executor can keep the property insured, serviced, secure, and physically accessible without discovering any of it by trial. It also means the digital layer of the house is named alongside the physical one, because a modern home’s lock, thermostat, and camera history may all sit inside accounts that appear nowhere in a filing cabinet. If a service arrives, bills, or renews, it belongs here, with the account it rides on.

Work and business

For anyone employed, freelance, or running a business, this category carries weight the others do not, because other people’s livelihoods and legal duties sit inside it. Record the employer and the route to its human resources or payroll contact; any benefits, pension, or insurance that flow through employment and that a family must claim or convert; and any equipment, access, or obligation that has to be returned or handed over. For the self-employed and business owners, go further and be unsparing: the business’s legal form, its bank and accounting arrangements, its accountant and attorney, its outstanding invoices and contracts, its client commitments with dates, and the systems — invoicing, email, file storage, client data — in which its working life actually resides. Add a plain statement of what should happen to the business on the owner’s death, even if the statement is only that formal advice lives in a named document in a named place. A one-person business with no such record does not pause when its owner dies. It defaults, misses, and breaches, in public, while the family is still arranging a funeral.

Done looks like this: a named contact for every organisation expecting something from the deceased, the location of the records each will ask for, and no client, employer, or partner learning of the death by accident from a bounced deliverable or an unanswered deadline that a single timely call would have prevented.

Domains and websites

Treat this category as its own discipline, because it is the one executors miss most completely and regret most sharply. For every domain: the name, the registrar, the account holding it, its renewal pattern, and its purpose. For every website: where it is hosted, what platform it runs on, who built or maintains it, and what it connects to — the forms, the email, the payments, the analytics, the backups. Then trace the dependencies in the other direction. Family or business email that runs on a domain dies with that domain. Logins across the internet are tied to email addresses under it. Recovery flows for dozens of unrelated accounts may route through a mailbox that exists only while a registration and a hosting arrangement stay paid and configured. The DreamHost incident discussed earlier in this article adds a second reason for precision here: the executor should know, from the inventory alone, which provider holds which service, so that when a provider announces an incident, the family can tell within minutes whether anything of theirs was inside it, instead of reconstructing their own infrastructure from memory under stress.

Done means no domain or site exists that is absent from the list, every renewal has a visible source of payment, and the consequences of each lapse are written next to the item — not “domain expires” but “family email stops.” Executors prioritise by consequence. Give them consequences to prioritise by.

Subscriptions and autopay

Subscriptions are the estate’s slow leak. Individually trivial, in aggregate they drain accounts, renew into years nobody uses, and — worse — sometimes carry things of value inside them that vanish when they lapse: stored files, purchased libraries, a phone number, a mailbox. List every recurring charge: the service, what it provides, the account or card it charges, and what the executor should do with it — cancel immediately, keep until a date, or transfer to a named person. Include the invisible ones, the annual renewals that produce no monthly reminder and surface only once a year, because an annual charge landing on a closing account eleven months into an estate is a small chaos all of its own. Where a subscription is the sole home of something the family wants — photographs in a storage tier, documents behind a plan, a creative library built over a decade — flag it in the entry itself, so cancellation is never performed blind by someone tidying charges they do not recognise.

Done, here, is a list an executor can execute line by line, with a decision already made for each line by the only person qualified to make it. The goal is not merely to stop waste. It is to ensure that nothing valuable is destroyed by an efficient executor cancelling their way down an unexplained bank statement, which is a real and recurring way families lose archives.

Devices and their passcodes’ whereabouts

List the devices: phones, tablets, computers, external drives, hardware keys, and any storage media with content on it. For each, record what it holds that matters, whether it is encrypted, and — following the split-knowledge principle from the previous section — where its passcode or recovery route can be obtained, rather than the passcode written bare beside the device name in every copy of the inventory. “Whereabouts” is the operative discipline. An entry might state that a phone’s passcode is in the sealed envelope held by a named person, or that a computer’s recovery key sits in a named location, or that a drive is unencrypted and labelled in a named drawer. The executor learns, from the vault, exactly where to go for each key, and the keys themselves live in their separate, guarded places. This is also the category in which to record the negative facts families never think to write down: the old laptop that holds nothing, the drive that was wiped, the phone that was replaced. An executor who cannot tell a wiped drive from the family archive will spend grief and money finding out.

Done means every device an executor will encounter in the house or the accounts is named, its significance is stated — including when the significance is none — and each locked device has a stated, reachable route to its key that does not depend on the device itself.

Documents and their original locations

Build this as a directory of authoritative paper and authoritative files. The will and any codicils. Property deeds and titles. Insurance policies. Marriage, birth, and citizenship records. Tax records and where the working files for them live. Any powers of attorney, healthcare directives, and guardianship papers. Contracts, loan documents, and court papers. For each item, the entry needs three things: what the document is, where the original is, and where a working copy can be read if the original is in a bank’s box or an attorney’s vault. Original location is the field everyone skips and everyone needs, because estates run on originals — institutions ask for them, courts ask for them — and because a family searching a house for a document that has spent twenty years in a safe-deposit box will tear the house apart and then, in the worst version, conclude the document does not exist.

Done means no document an institution will request in the first ninety days requires a search. Every one of them can be produced, or its holder visited, from the inventory alone. VaultBook’s search, including its ability to find text inside attachments and scanned material, turns this section from a static list into something an executor can interrogate — searching a name, an institution, a policy type — but the search is only as good as the directory beneath it. Write the directory.

People to notify

The final category is people, and it is the one whose absence is felt socially rather than financially, which does not make it hurt less. List who must be told, in rough order: immediate family, the employer or business contacts from the earlier category in their personal capacity, close friends, the communities and institutions the person belonged to, and any professional who should hear it from the family rather than from an invoice returned unpaid. For each, a name and a route — a phone number, an email, a mutual contact who can carry the news properly. Include the people who are easy to forget because they live in one corner of a life: the former colleague who became a friend, the group that met monthly, the online community where the person was a daily presence under a familiar name. And record the person’s own wishes about notification where they exist — who should be told privately first, what should be posted publicly, and where — because the family’s first public act in grief will otherwise be improvised, and improvisation in that moment is how estranged relatives learn of a death from a social feed.

Done means a family member who knows almost nobody in the deceased’s wider life — a common situation when the executor is a spouse’s sibling, an adult child from another city, an attorney — can still notify everyone who matters, in an order the deceased would have recognised as right.

Keeping the inventory current

An inventory decays, and it decays silently. Accounts are opened for a single purchase and forgotten. Cards are replaced and autopay moves. A domain is registered on a whim and becomes, five years later, the address the family’s email depends on. The executor’s inventory is only trustworthy if keeping it current is built into ordinary life rather than left to an annual act of heroic administration that, in practice, happens twice and then never again. Two rhythms, working together, are what real households sustain.

The first rhythm is capture at creation. Whenever an account is opened, a policy taken out, a device bought, a domain registered, or a subscription started, its entry is added to the vault at that moment — in the same sitting, as part of the act of creating the thing, while the details are on the screen in front of you and cost nothing to record. This single habit does most of the inventory’s work forever, because accounts are created one at a time, in calm moments, and each arrives with its own facts attached. Creation-time capture also scales in the right direction: the entry is written by the person who chose the account and knows what it is for, rather than reconstructed later by the same person guessing at a statement line. Make it a rule with no exceptions for small things. The small things are the ones nobody reconstructs.

The second rhythm is the scheduled review, and its job is different: not addition but reconciliation. Sit with the vault at a steady interval — many people tie it to a date they already observe, a birthday, the turn of the year, the week the tax records are assembled — and read the whole inventory against reality. Close the entries for accounts that no longer exist. Correct the ones whose purpose or provider has changed. Check that the whereabouts recorded for originals still match where the originals actually are, that the people named as holders of envelopes and keys are still the right people, still reachable, and still willing. Confirm the copy of the vault held by or for the executor is the current one, and that the split arrangement still works as designed — the passphrase holder knows they hold it, the sealed envelope is where the entry says it is, the USB copy has been refreshed. A legacy vault that lives in VaultBook makes this review unusually practical: its version history shows what changed and when, so a review can start from the changes rather than from a blank re-read, and its full search lets you test the inventory the way an executor will use it, by hunting for an institution or a document and seeing whether the trail completes.

There is a temptation, during review, to reorganise — to rebuild the inventory in a better structure, rename everything, start fresh. Resist it in favour of correction. An inventory’s value to an executor lies in its stability and its boring completeness, not in the elegance of its current scheme, and every reorganisation is a chance for an entry to fall between the old system and the new one. Add at creation, correct at review, delete only what has genuinely ceased to exist, and let the record grow the way a household actually grows: incrementally, a little untidily, and always findable.

Finally, tell the executor the inventory exists, where the vault copy is, and how the passphrase reaches them — and do it while the telling is easy, in an ordinary conversation, not in a letter to be opened on the worst day. A plan nobody knows about is indistinguishable from no plan until the moment it is needed, and the moment it is needed is the moment nobody has spare capacity to discover it. The inventory, the split knowledge, the platform arrangements, the review rhythm — all of this machinery has one purpose, which is to let the people you love spend the first hard weeks being a family, rather than being detectives in your filing system. Build it to that standard, keep it current by habit rather than by effort, and it will be ready on the only day its readiness cannot be postponed.

Building the vault: entries, labels and per-entry encryption

A legacy vault fails in two opposite ways. It is either so scattered that no one can find anything in it, or so monolithic that opening it means opening everything at once. Both failures come from the same mistake: treating the vault as a container instead of as an architecture. You do not need a clever folder tree or a master document that tries to hold your whole life in one scrolling page. You need small, named, separable pieces, each one complete enough to use on its own, and a labelling system that lets a stranger — or a tired, grieving version of someone you love — find the right pieces in the right order.

Start with the entry as the unit of work. One entry per account. One entry per document. One entry per person who will need to be contacted, paid, notified, or thanked. One entry per property, policy, device, or obligation that someone else might have to take over for a month or for good. An entry for the mortgage servicer is not the same entry as the house itself. The house entry holds the deed location, the insurance policy number, the alarm code arrangement, the name of the plumber who knows the shutoff that sticks, and the property tax schedule. The mortgage entry holds the servicer, the account reference, the payment method, the escrow notes, and what happens if a payment is missed. Splitting them feels fussy while you are building it. It saves hours later, because an executor and a surviving spouse do not ask the same questions at the same moment, and they should not have to wade through each other’s information to get to theirs.

Each entry should answer five things without making the reader hunt: what this is, why it matters after you are gone or incapacitated, where the authoritative original lives, what the next action is, and when it needs attention again. That last point matters more than people expect. A policy number without a renewal date is a snapshot. A renewal date without an instruction — renew, cancel, let lapse, call this broker first — is a riddle. Write the instruction in plain language, as if to a capable adult who does not share your habits. Do not write “handle as usual.” No one else knows what usual was.

Labels do the architectural work that folders cannot. A folder forces a choice: does the life insurance entry live under Money or under Family? In Vault Book, labels let the same entry belong to several views at once without being copied, moved, or duplicated. That is exactly what legacy planning needs, because the same fact serves different readers on different timelines.

Build a small, deliberate label set and use it consistently, rather than inventing a new tag for every entry. A set that holds up in practice looks something like this. The label executor-first-week gathers everything that cannot wait: the will’s location, funeral wishes if they exist, immediate bills that will bounce, pets that need feeding, people who must be told within days, and access instructions for the house. The label money gathers bank accounts, investments, debts, recurring payments, tax obligations, and the professional contacts who manage them. The label home gathers the property, utilities, insurance, maintenance contracts, keys and codes, and the practical knowledge that keeps a building running. The label family-archive gathers photographs, letters, recordings, certificates, and the stories that give them meaning — material that matters enormously and urgently to no deadline at all, which is precisely why it needs to be separated from the urgent material so it is not lost in it or mistaken for it. The label notify gathers the long tail: memberships, subscriptions, loyalty accounts, community groups, online communities, and services that should be closed, transferred, or simply told.

You will add others as your life requires — business, medical, vehicles, digital-accounts, children, parents — but keep the core set small enough that you can hold it in your head. If you cannot remember your own labels, your executor will not decode them under pressure. Consistency beats cleverness. Use the same label spelling every time, review the label list itself once a year, and merge near-duplicates ruthlessly. Twenty entries under one clear label are useful. Twenty labels with one entry each are a second puzzle stacked on top of the first.

Now consider why per-entry encryption, rather than a single password for the whole vault, is the design decision that makes a legacy vault honest. In Vault Book, encryption operates at the level of the individual entry, using AES-256-GCM with a key derived through PBKDF2 via the Web Crypto API. In practical terms that means any given entry can be protected with its own passphrase, independent of every other entry. The vault file itself — a single HTML file of about 1.5 megabytes that makes zero network requests and runs entirely on the owner’s machine — can be opened and browsed in its unencrypted portions by anyone who holds it, while the sealed entries inside it remain unreadable without their specific passphrases.

That granularity maps directly onto how families actually work. An all-or-nothing account password forces a choice no thoughtful person wants to make. Either the executor gets the one password and thereby gets everything — the financial records they legitimately need, and also the private journals, the unsent letters, the draft memoir, the candid notes about family members, the medical reflections you wrote for yourself alone — or the executor gets nothing, and the practical information dies behind the same lock as the private information. Most people, faced with that choice, quietly choose nothing. They tell themselves they will set something up later, with finer control, when a better tool appears. Later becomes the emergency.

Per-entry encryption dissolves the dilemma because the decision becomes entry by entry, person by person. Seal the executor’s operational entries under a passphrase the executor will receive through whatever channel you arrange — a sealed envelope with your attorney, a note in the safe deposit arrangements, a conversation held while you are well. Seal a spouse’s or partner’s entries under a different passphrase that only they hold, covering household finance, shared property, and the personal material that belongs to the marriage or partnership rather than to the estate process. Seal a third group — journals, private letters, early drafts, reflections you are not sure anyone should read — under a passphrase you share with one named person, or with no one at all. An entry encrypted with a passphrase nobody else knows is not a planning failure if that was your intent. It is a decision, executed in advance, that this material ends with you. Vault Book’s design lets you make that decision cleanly instead of by accident, through the blunt instrument of a single lost password.

The reverse is also true, and worth stating plainly. Some entries should not be encrypted at all. The entry that explains how the vault works, where its copies live, who holds which passphrases, and what to do in the first forty-eight hours should be readable by whoever picks up the file. Locking the instructions inside the lock is the most common self-inflicted wound in amateur legacy planning. Leave the map unsealed. Seal the treasure selectively.

Version history completes the build, and its value is specific to legacy work. Every entry in Vault Book carries a history of its changes, so the inventory you build today does not silently overwrite the inventory you built last year. For a living document — and a legacy vault is useless if it is not living — that audit trail matters in three ways. First, it disciplines the owner: knowing that changes are recorded encourages you to update deliberately rather than scribble and forget. Second, it protects the executor: if an account number changed, a policy was replaced, or a contact died, the history shows when the change was made and what it replaced, which is often the clue that resolves a discrepancy with a bank or insurer. Third, it protects the family from misreading absence. An entry that was deleted looks different from an entry that never existed, and an entry whose contents shrank from a full page to a line looks different from one that was always brief. Grief makes people suspicious of gaps. A visible history turns many of those gaps into ordinary, dated, human edits.

Build in small sessions rather than in one heroic weekend. Ten entries done properly — complete, labelled, encrypted as intended — are worth more than a hundred stubs. Start with executor-first-week, because that label defines the smallest vault that would still help. Then money, then home. Leave family-archive for when the habit is established; it expands forever if you let it, and it should, but not at the expense of the operational core. When an entry resists being written — because the information is elsewhere, or the decision behind it is unmade — write that fact into the entry itself and label it accordingly. An entry that honestly says the original deed has not been located since the move, and names the two places it might still be, is a useful bequest. Silence about it is not.

The paper half: boxes, backs of photographs and the family archive

Every digital legacy plan eventually meets a cardboard box. It sits in a closet, a garage, an attic, or the spare room of a parent’s house, and it contains the part of the family record that never made it into any account: thousands of snapshots in drugstore envelopes, school portraits with the year trimmed off, holiday prints curled at the edges, negatives nobody can read any more, letters tied with string, certificates folded into Bibles, and photographs of people standing in front of houses that no longer exist, smiling at a camera held by someone whose name is also lost. The digital vault matters because it can give this material a structure before the last people who recognise those faces are gone. But the box has to be understood on its own terms first, because the mistakes people make with paper are different from the mistakes they make with passwords, and they are just as permanent.

Anyone who spends time reading discussions among family historians in places like Reddit’s r/Genealogy community encounters the same emotional weather, in post after post, wearing different clothes. There is guilt in both directions at once. People feel guilty for keeping so much — for the space it takes, for the burden it will become, for the suspicion that most of it matters to no one but them — and guilty for every photograph they have ever thrown away. Woven through that guilt is grief by proxy: stories of a relative who, clearing a house quickly after a death, discarded bags of photographs as rubbish, and of the family members who learned about it months later and understood instantly that what was lost could not be re-created at any price. A scanned bank statement can be reissued. A 1947 snapshot of a grandmother laughing in a kitchen that was demolished in the 1970s cannot. The asymmetry explains the hoarding, and it explains the paralysis. When everything might be the only copy of something, deciding what to discard feels dangerous, so nothing gets decided, and the box passes intact to the next person, who inherits both the photographs and the paralysis.

The second recurring theme is harder and sadder: the inherited box with no writing on the backs. Earlier generations were inconsistent annotators. Some people pencilled a name, a place, and a date on every print as a matter of discipline. Many more wrote nothing, or wrote only a first name — as if “Margaret at the lake” would remain self-explanatory forever. Families open these boxes decades later and discover that identification is a closing window. In accounts shared by genealogists, a typical outcome is that roughly a third of the people in a box like this eventually get identified, and that only because older relatives were asked in time, recognised faces from their own youth, and supplied context no document contained. The rest remain well-dressed strangers to their own descendants. The photographs survive; the knowledge that made them meaningful does not, because knowledge lives in people and people leave.

Out of those frustrations, experienced family historians have converged on a set of working habits that are worth adopting wholesale, because each one was learned the expensive way. Scan the backs as faithfully as the fronts. The back is not blank space; it is often the document. Faint pencil marks that are nearly illegible on glossy paper can become readable in a scan, where contrast can be adjusted and the image enlarged. Studio stamps give a town. A processing date printed along the edge narrows a year. Even a smudged number from a lab sequence can cluster a batch of prints into a single afternoon. People who scanned only the faces and returned or discarded the originals have described realising, too late, that they had preserved the image and destroyed the evidence.

Give every photograph a permanent number, and track what you know in a list keyed to that number, rather than endlessly renaming and reshuffling folders. Folder shuffling feels like organising and behaves like erosion: each reorganisation breaks the previous references, and a filename like “Grandma_final2” carries no information at all. A stable numbering scheme — box one, item forty-three, say, recorded once and never changed — lets every other fact attach to something that stays put. Alongside the number, track a confidence level for each identification. This person is certainly your great-aunt, named by two relatives independently. That person is probably her brother, based on age and resemblance. The third is a guess offered by one cousin who was unsure. Confidence levels sound bureaucratic until you imagine your grandchild, forty years from now, treating your guess as a fact and building a family tree on sand. Recording uncertainty is a kindness to the future. It is also, frankly, a relief in the present: you no longer have to wait until you are sure before you can record anything.

Date the photograph from physical clues before you try to identify the people in it. This reversal of the natural order is one of the most useful disciplines in the whole field. Clothing, hairstyles, cars, shop signs, the presence or absence of a building, the age of a known child, the format of the print itself — all of these can place an image within a few years, and a date range eliminates most wrong identifications immediately. A man cannot be your grandfather in a photograph taken a decade before he was born, however strong the family resemblance. Establish when, then argue about who.

Offer material to family first, before any decision to discard. Branches of a family value different things; the cousin researching one surname will rescue exactly the envelope you were about to let go, and the sibling who wants nothing may want the one portrait of a parent that you assumed was duplicated elsewhere. And above all, label while the labellers are alive. Every identification session with an elderly relative, however short, recovers information that exists nowhere else on earth. The recurring regret in these discussions is almost never that someone asked too early. It is that they meant to ask, and then the funeral came first.

Vault Book’s role in this work is not to replace the box. It is to become the list, the index, the memory, and the bundle-maker that the box always needed. The workflow begins with inventory. If the scans already exist as a drive full of folders — the common case, after someone in the family bought a scanner and spent a winter at it — the File/Folder Analyzer can inventory that drive, mapping what exists, where it sits, and how it is distributed, so the legacy plan rests on a real census rather than a feeling that there is “a lot scanned, probably.” For the images themselves, the Photo/Video Explorer works with the digital files and their EXIF data: the embedded dates, camera information, and technical metadata that modern photographs and competent scans carry. EXIF will not identify a face from 1958, but it anchors the digital side of the archive, separates originals from copies, and keeps technical facts attached to the image instead of in someone’s memory.

Searchability is where the archive stops being a warehouse. Vault Book’s search includes OCR powered by tesseract, which means scanned handwritten and printed documents — letters, certificates, annotated backs, newspaper clippings, funeral programmes — become searchable text rather than pictures of text. Attachment indexing extends the same reach to files held alongside entries. So the back of a photograph, once scanned, can contribute its pencilled place-name to search; a letter mentioning a house can be found by the street name decades later; a certificate can be retrieved by the name it records, spelled as it was spelled then. Combined with ordinary and semantic search, including the built-in question-and-answer style search over your own material, the executor or the family historian can ask the archive questions in the form they actually think of them, instead of needing to remember your filing logic.

Assembly is the final step, and for legacy purposes it may be the most valuable. The PDF tools — merge, split, and compress — let you build a clean document bundle per person or per event out of the scattered evidence: the birth certificate, the marriage record, the obituary, the identified portrait, the letter in their hand, gathered into one file that can be handed to a relative, an attorney, or a local archive without handing over the entire vault. Splitting matters just as much: the forty-page bundle a solicitor sent as a single scan can be divided into its constituent documents, each filed as its own entry, each labelled and searchable on its own terms.

Labels, carried over from the operational vault, hold the confidence system together. Use the family-archive label for the whole collection, then apply your identification labels with the same consistency you gave the executor labels. A photograph identified with certainty, a photograph identified provisionally, and a photograph still unknown are three different objects from a researcher’s point of view, and your labels should say so. The permanent number lives in the entry title or its opening line. The confidence, the source of the identification, and the date range established from physical clues live in the entry body. When a relative confirms or corrects an identification, version history preserves the earlier state and the change, so the archive records not just what the family believes, but how it came to believe it. That is a real archive, not a pile of scans with ambitions.

Do this work in the order the evidence demands: inventory first, backs scanned, numbers assigned, dates estimated, identifications recorded with confidence, bundles assembled last. The box will still be a box. But it will also, for the first time, be legible to someone who never met the people inside it.

Voices before they are gone: recording and transcribing family memory locally

Photographs are silent about the things that identify them best. A print can show you a porch, a dress, a car, and four people arranged by height, but it cannot tell you that the family called that porch by a nickname, that the dress was borrowed, that the car belonged to a neighbour nobody liked, or that the tall boy on the end was not a brother at all but a lodger who stayed one summer and was spoken of for fifty years. That layer of information lives in speech. It surfaces in kitchens, in car journeys, in the pauses while an elderly relative holds a photograph and thinks. And it vanishes with a completeness that surprises every family the first time it happens, because a voice feels permanent while the person is still using it.

Among family historians, one piece of advice recurs with almost moral force: sit with the oldest relative you have, while you still can, and record. Not interview, exactly — interviews make people perform — but sit, bring a few photographs, make tea, press record, and let conversation do what conversation does. The value is rarely in the set-piece stories, the ones polished by decades of retelling. It is in the offhand remark. A grandmother glances at a snapshot she has supposedly never explained and says, without being asked anything clever, that this was taken behind the house with the blue door, the winter after the roof leaked, before your mother cut her hair. In one sentence she has identified the place, narrowed the date, and explained why a known person looks unfamiliar. Three entries in your archive just became accurate. Genealogists describe whole boxes unlocked this way: one afternoon of apparently rambling talk resolving the identities in dozens of prints, because memory is associative, and a house summons its occupants, and a porch summons the summer, and the summer summons the lodger’s name.

The practical obstacle is what happens to the recording afterwards. A ninety-minute conversation on a phone is an intimidating object. Nobody relistens to it. It sits in a voice-memos folder with a date for a name, too long to browse, too precious to delete, effectively sealed by its own length. Meanwhile its contents — the names, the identifications, the stories that explain the archive — remain locked inside audio that no search can reach and no executor will ever sit through at random, hoping for the relevant minute.

Vault Book’s toolset is built for precisely this bottleneck, and the crucial property is where the work happens. The MP3 cutter and joiner let you divide a long recording into its natural episodes — the segment about the house, the segment about the war years, the segment about the sister who emigrated — and join fragments from different sessions that belong to the same subject. Local transcription, using Whisper running on the owner’s own machine, then converts that speech into searchable text without the recording ever leaving the computer. Read that last clause again, because for family material it is the whole ballgame. These interviews contain exactly the things a thoughtful person does not upload to a stranger’s transcription cloud: candid assessments of relatives living and dead, family medical history mentioned in passing, old conflicts, illegitimate births in generations where that word carried real shame, money troubles, estrangements, the true reasons for a feud that the official family story politely omits. Uploading hours of that to a third-party service — to be processed on unknown servers, retained under unknown policies, and potentially used in ways no one in the family consented to — is a privacy decision made by default, in a hurry, by whoever happened to do the transcription. Keeping the audio and the transcript local means the decision about who ever hears or reads this material stays where it belongs: inside the family, made deliberately.

Once transcribed, the recording changes character entirely. The transcript can live as entries in the vault, divided by subject, labelled under family-archive, and linked — through Vault Book’s related notes — to the very photographs and documents the conversation identified. The remark about the blue door becomes attached to the scan of the porch photograph. The story about the emigration becomes part of the bundle for that person. Search can now find the passage by the name mentioned in it, and the question-and-answer search over your own material can surface it when a descendant asks the archive a natural question years later. Inline audio and video players mean the entry is not a replacement for the voice but an index to it: read the transcript to find the moment, then listen to the moment in her actual voice, with its laugh and its pause before the name came back to her. The transcript gives the archive reach. The audio gives it presence. A serious legacy plan keeps both, joined.

Handle consent and sensitivity as first-class parts of this work, not as afterthoughts. Recording should always be open and agreed — a visible phone or recorder, a simple explanation that you want the family’s stories kept, and a genuine willingness to stop when a subject is not for keeping. Some relatives will happily talk for the record about everything except one marriage, one child, one year. Honour that boundary in the archive itself. The segment can be cut and excluded, or kept and sealed. This is where per-entry encryption earns its keep a second time, in a gentler register than the executor’s operational entries. A story told for the immediate family, not for the wider clan and certainly not for eventual publication, can be encrypted under a passphrase held by the people it was meant for. A story the teller was happy to share broadly can sit unsealed under family-archive, ready for any descendant. And material recorded in confidence, shared with you because you are you, can be sealed with no shared passphrase at all — preserved by you, readable by you, and effectively retired when you go. Not everything captured should be transmitted. The vault lets you grade those decisions instead of forcing you to choose between recording everything openly and recording nothing.

Start smaller than your ambitions. One relative, one afternoon, a handful of photographs, and no agenda beyond listening. Transcribe it within the week, while you can still correct the names the transcription misheard and annotate who “he” referred to in a story where three men share a first name. Cut it into its episodes and link them the same week. Then do it again next month. Families who wait for the perfect, comprehensive oral-history project tend to record nothing; the project is always postponed until the relative is stronger, or the house is quieter, or the right equipment arrives. Families who record imperfectly, on an ordinary afternoon, end up with the porch, the blue door, the lodger’s name, and the laugh — preserved, transcribed, searchable, and still on their own machine, where it was always meant to stay.

Dates that outlive you: calendar, due dates and the Recent, Due and Expiring sidebar

A legacy vault is usually tested in the worst month of someone’s life, and what fails first in that month is rarely a password. It is a date. The insurance renewal that lapsed eleven days after the funeral because nobody knew it was due. The domain name — perhaps the one attached to the family email addresses — that expired during probate and was gone before the executor knew it existed. The property tax instalment that attracted penalties while the estate’s accounts were frozen. The driving licence, passport, or residence document of a surviving spouse, discovered to be expired only at the counter where it was needed. Grief is cognitively expensive; it consumes exactly the attention that deadlines demand. A plan that ignores the calendar is a plan that works beautifully in theory and sheds penalties, lapses, and lost coverage in practice.

This is why the dated layer of the vault deserves the same design care as the encrypted layer. Vault Book includes a built-in calendar, and — more important for legacy purposes — a Recent, Due and Expiring sidebar that continuously surfaces what has changed lately, what is due, and what is approaching expiry. That sidebar changes the nature of the inventory. A static list, however thorough, begins going stale the moment it is written, and gives no sign of which parts have gone stale first. A vault that actively surfaces approaching dates behaves more like a conscientious assistant: open it, and the month’s obligations announce themselves before you have searched for anything. For an executor in month one, who does not yet know what questions to ask, that difference is enormous. Search rewards people who already understand the estate. The sidebar helps the person who does not.

Build the dated layer by sweeping your life once for anything with a clock on it, and giving each item an entry with an explicit date and an explicit instruction. Insurance comes first, because its failures are the least forgivable: home insurance, vehicle insurance, life policies with premium schedules, health cover, travel policies that renew automatically, and any policy where a missed payment voids protection precisely when a household is least able to absorb a loss. For each, record not just the renewal date but the renewal behaviour — does it auto-renew, must it be actively renewed, does the premium leave a particular account, and should the executor continue it, amend it, or let it end? A house that will be sold in six months still needs cover until the sale completes. A car nobody will drive still needs a decision, recorded, rather than a default discovered by a fine.

Domain renewals deserve a prominence that feels disproportionate until you trace the dependencies. If your email, your family’s email, your two-factor recovery paths, or a small business presence hang off a domain, that domain’s renewal date is load-bearing infrastructure for the entire estate. Record the registrar, the renewal date, the payment method, and the knock-on effects of losing it. The same applies to any registration the household quietly depends on: vehicle registration, professional licences, business filings, permits, memberships with renewal windows, warranties with claim deadlines, and identity documents for every adult in the house. Document expiries are a special cruelty because they surface at moments of maximum friction — travel, hospital administration, a bank appointment — so record expiry dates for passports, licences, permits, and cards for the surviving household, not only for the person whose estate this is.

Then work through the slower clocks: property tax dates, loan review dates, mortgage fix expiries, pension and benefits correspondence deadlines, tax filing dates and the quarters that precede them, medical review cycles, school and care fees, and the maintenance contracts — boiler service, alarm monitoring, water systems — whose lapse quietly cancels a warranty or a response service. Not every date belongs in the vault at equal weight. The discipline is to ask, for each one, a single question: if nobody acted on this date because I was not there, what would it cost, and who would pay? If the answer is money, coverage, legal standing, or a dependent person’s stability, the date earns an entry.

The sidebar also serves the owner, long before it serves the executor, and this dual service is what keeps the vault alive. A legacy plan that only matters after your death competes for your attention against everything in your actual life, and loses. A vault whose Due and Expiring view helps you this quarter — catching the renewal you would have missed, reminding you which document expires before the planned trip — gets opened, and therefore gets maintained, and therefore still works on the day someone else opens it. When you verify an entry’s date, update the entry. When a policy is replaced, the new entry supersedes the old and version history preserves the trail, so the executor who finds a reference to the old policy number in a bank letter can reconcile it against the vault instead of concluding the vault is wrong. Recent matters here too: the sidebar’s view of lately changed entries lets a spouse or executor see, at a glance, what the owner touched last — often the best available map of what the owner most recently knew to be in flux.

None of this maintains itself, so give the vault a review rhythm anchored to something that will happen anyway. Choose an existing annual event with a fixed place in your calendar — a birthday, a new year, the anniversary of the house purchase, the week the tax return is prepared — and attach the vault review to it. Annual is enough for the full sweep: read the Due and Expiring horizon for the coming year, confirm the executor-first-week label still describes reality, check that copies of the file live where the plan says they live, and re-run the simple test of whether the people named in the plan still hold the roles it assigns them. Add a lighter mid-year pass if your affairs change often, triggered by events rather than dates: a move, a job change, a marriage, a diagnosis, a new child, a sold property. Event-triggered updates keep the vault honest between anniversaries, because most legacy plans are not defeated by the passage of time. They are defeated by one specific change — a new account, a closed account, a different executor — that never made it into the file.

A final, practical note: record dates in full, unambiguous form, with the year, and write the instruction alongside the date in the same entry. “Renews in March” is a sentiment. “Renews 14 March 2027; auto-renews from the joint account; executor to continue until the house is sold, then cancel and claim any pro-rata refund” is a bequest. The person reading it may be doing so at a kitchen table at midnight, with a pile of unopened post beside them. The vault’s job, on the dates front, is to be the one pile that is already sorted.

The handover rehearsal: making one other person able to open it

The most honest finding in discussions of emergency and legacy planning — visible across preparedness communities, family-organising threads, and the rueful follow-up posts people write after a plan met reality — is that most plans were never finished in the only sense that counts. Not unfinished on paper. Unfinished in the world. People describe emergency kits carefully assembled, printed, and then never stored where the plan said they would be, or stored and never mentioned to the household they were made for. They describe a partner who, with excellent intentions, wrote down every password in the house, hid the list somewhere safe, and then — in the detail that makes strangers wince in recognition — forgot where safe was. They describe binders: magnificent binders, tabbed and indexed, that demanded so much maintenance that updating them became a project in itself, deferred until the binder described a household that no longer existed. The plan existed. The handover never happened. From the outside, those two states are indistinguishable.

The rehearsal is the practice that closes that gap, and it should be treated as a required stage of building the vault, not a nice extra for the especially organised. Its premise is blunt: a legacy plan is not done when you can open it. It is done when one other specific person, on their own device, without you in the room talking them through it, can open it and use it. Everything before the rehearsal is drafting.

Choose the person before you choose the mechanics. For most households the rehearsal partner is the executor, a spouse or partner, or — where those roles are filled by someone distant or elderly — the adult child, sibling, or trusted friend who would realistically be the first competent person on the scene. If the executor named in your will and the person who would actually handle the first fortnight are different people, rehearse with the second one, and make sure the vault’s opening entry names both and explains the division. Then arrange the session properly. This is not a corridor conversation or a text message saying the file is in the usual place. Sit down, or get on a call with screens shared, and let them do it.

The test itself is simple and deliberately concrete. The other person opens Vault Book on their own machine — remember that the vault is a single HTML file that runs locally, with no account to sign into and no server to be reached, so opening it on their device is a real test of the file copy and the arrangement, not of a login — and completes three tasks you name in advance. Find the entry that says what to do in the first forty-eight hours. Find a specific financial entry: the mortgage, say, or the main insurance policy, and read back the next action and the next date. Find one family-archive item: an identified photograph, or the transcript passage that explains it. Three tasks, chosen because they cross the vault’s three worlds — instruction, operation, and archive — and because failure on any one of them teaches you something different. If they cannot find the first entry, your opening instructions or your labels are unclear. If they find the financial entry but cannot say what to do next, the entry is a record, not an instruction, and needs rewriting. If the archive item eludes them, your numbering, labelling, or linking has drifted from how another mind organises the same material.

Then comes the most valuable part, and the part owners most often skip because it stings a little: ask them what confused them, and believe the answer. Every hesitation is data. The label that seemed self-evident to you and meant nothing to them. The abbreviation you did not know you used. The entry that assumed the reader knew which house, which account, which Margaret. The passphrase arrangement that works in theory and collapses when the person describes, out loud, the order in which they would actually receive things after a death — the attorney’s office closed for a holiday, the envelope in the safe they cannot open, the copy of the file on a machine they do not have the password for. Rehearsals surface sequencing problems that no amount of solo proofreading finds, because solo proofreading tests the vault against the mind that built it. That is the wrong mind. Revise from the rehearsal notes the same week, while the confusion is still specific, and record in the vault’s opening entry that the rehearsal happened and when. That single dated line does quiet psychological work for the executor later: it tells them this plan was tested by a person, not merely assembled by one.

Copies and locations need the same unsentimental clarity. Decide, and write down in the unsealed opening entry, where the copies of the vault file live. The primary copy lives on the owner’s machine, in a known location, not buried in a downloads folder under a filename from three drafts ago. A second copy lives with the executor, the rehearsal partner, or the attorney — someone outside the house, so that a fire, a theft, or a seized device does not take the plan with the problem. A third, offline copy — on physical media, stored somewhere sensible and named in the plan — guards against the mundane catastrophe of accounts locked, machines failed, and clouds unreachable at exactly the wrong moment. Because the vault is one file, copying it is trivial; because it is trivial, people forget that copies age. State the updating rule alongside the locations: whenever the vault changes materially, the outside copies get refreshed, and the review rhythm from the previous section is when that refresh is verified. A two-year-old copy held by your executor is better than no copy. It is not the plan, and the opening entry in that old copy should be honest, whenever it is next written, about the date it represents.

Finally, the social layer, which is not soft at all. Telling people the plan exists is part of the plan. The executor should know they are the executor before the will is read. The rehearsal partner should be able to tell other family members, calmly and with authority, that a vault exists, roughly what it covers, and where the instructions begin — because in the first days after a death, several well-meaning people will start improvising in parallel, and the sentence “there is a plan, and here is where it starts” prevents more damage than any single entry prevents. Conversely, the wider family does not need the vault’s contents, its passphrases, or a guided tour. Existence is public within the family. Contents are shared on the graded basis you built with per-entry encryption. That distinction — everyone knows there is a map, only named people hold keys to named rooms — is what makes the arrangement feel fair, and fairness, in the weeks after a death, is load-bearing.

Rehearse again after any major change: a new executor, a move, a marriage or separation, a significant change in health. Keep it short the second time. The goal is not ceremony. The goal is that on the worst day, at least one other person has already done this once on a calm day — opened the file, found the first entry, and discovered that the plan works and that they, personally, can work it. Confidence, rehearsed once, is a real asset in an estate. Surprise, however well documented, is not.

Incapacity is the harder case nobody plans for

Almost every legacy tool, and almost every conversation about legacy planning, is built around death. Death is the event the law organises itself around: the will speaks, probate opens, executors are empowered, certificates are issued. But the scenario that is statistically ordinary, logistically brutal, and almost entirely unplanned for in most households is not death. It is incapacity — the heart attack survived but followed by weeks in hospital and months of convalescence, the fall that breaks more than bone, the diagnosis that requires treatment abroad, the cognitive decline that arrives gradually enough that no single day looks like the day to activate a plan. In incapacity you are still alive, your obligations are still entirely yours in law, your accounts are still in your name — and you cannot run any of it. The mortgage does not pause for your rehabilitation. The insurance premium does not know you are in a ward. The household runs on, consuming money, decisions, and deadlines, while the one person who knows how it all fits together is in no state to explain it.

Hold the two cases side by side and the planning gap sharpens. At death, there is at least a recognised machinery: slow, expensive, and frustrating, but legible. In incapacity, the machinery depends almost entirely on what was arranged privately, in advance, while the person was well. Who can pay the mortgage this month — not own the house, not sell it, just keep the payment made from the right account on the right date? Who knows where the scan of the health insurance card lives, and the details of the supplementary cover, and the name of the consultant’s secretary, and which pharmacy holds the repeat prescriptions? Which subscriptions and services keep the household running and must be kept alive — broadband, mobile phones, the alarm monitoring, the care visits, the software a working spouse depends on — and which can lapse without consequence? Where are the car keys, the boiler’s quirk, the neighbour with the spare key, the dog’s medication schedule? Death planning asks who settles your affairs. Incapacity planning asks who can operate your life, at short notice, at partial scale, for an unknown duration, and then hand it back to you.

The same vault answers both cases, and that is not a marketing convenience — it follows from the design decisions already made. The executor-first-week label, built for a death, contains most of what a stand-in needs in the first week of a hospital stay: the urgent bills, the house instructions, the people to notify, the pets. The money and home labels cover the operating system of the household. The Due and Expiring sidebar, which serves the executor in month one, serves the stand-in in week one even better, because incapacity has no probate timetable to impose order; whatever surfaces the next deadline first is what saves the household from the slow accrual of small disasters. The difference between the two cases is not the information. It is the cast and the keys. For death, the executor receives passphrases through arrangements that activate then. For incapacity, you need a living handover: a trusted person, chosen while you are healthy, who holds — or can promptly obtain — the passphrases for the operational entries, and who understands that their authority is practical and temporary, exercised on your behalf and accountable to you when you recover. Choose that person with the same care as an executor; in many households it will be the same person, or a spouse wearing both hats, but name the incapacity role explicitly rather than assuming it. Assumptions are how a devoted partner ends up, phone in hand outside a ward, realising that every account, code, and document they need is sealed behind arrangements designed to open only upon a death that has not happened.

Per-entry encryption is what makes the living handover tolerable to arrange. Handing someone the operational core of your life while you are well is an act of trust that many people balk at when it is framed as all-or-nothing — and reasonably so. The graded design lets you share what incapacity actually requires and nothing more: the household finance entries, the insurance and medical administration entries, the property and bills entries, under the passphrase you share with your stand-in. The journals stay sealed. The private letters stay sealed. The drafts and reflections were never part of the household’s operating system, and incapacity does not make them so. That selectivity is what allows the conversation to happen at all. People delay incapacity planning for years because the imagined version involves surrendering total access to their digital life. A vault that can be opened in layers turns a surrender into a delegation, and delegations can be discussed, bounded, rehearsed, and — if trust or circumstances change — re-keyed by changing the passphrases on the affected entries and sharing the new arrangement with the new person.

Rehearse incapacity the way you rehearsed the death handover, but with its own scenario, because the failure modes differ. Give your stand-in a simple drill: you are unreachable for a month, starting today. Pay the mortgage. Find the insurance card scan. Name the three services that must not lapse and say how each is paid. Find who to call about the house if the heating fails. If they can do those four things from the vault on their own device, the household can survive your absence. If they cannot, you have learned it on a calm afternoon instead of from a hospital bed, which is the only kind of learning this subject reliably offers twice.

An honest note belongs here about the platform legacy tools, because many people assume — having ticked a box in a phone setting once — that this ground is covered. For incapacity, it essentially is not covered at all. Apple’s Legacy Contact arrangement is a death mechanism: access for the designated contact is granted after death, and Apple requires a death certificate as part of the verification. Whatever its merits for its intended purpose, it offers nothing to the spouse who needs access during a hospital stay, because the qualifying event, by design, has not occurred. Google’s Inactive Account Manager works on inactivity rather than death, which sounds closer to the incapacity case until you look at the timing: the shortest inactivity period it offers is three months. A household can default, lapse, and unravel a great deal in three months of silence, and the system is not designed to distinguish “inactive because incapacitated last Tuesday” from “inactive because the account was forgotten.” It is a timer, not a handover. Neither tool is badly designed for what it attempts. Neither attempts the thing a family in a hospital corridor actually needs: immediate, graded, practical access, arranged by a person who is still alive to arrange it, for a person they have chosen, covering the operational facts of a shared life. That gap is not an edge case in digital legacy planning. For most families, it is the main case — and it is the one your own vault, built locally, sealed entry by entry, dated, rehearsed, and held by people who know it exists, is positioned to close.

VaultBook against the note apps you already use

Every note app on your phone or laptop was designed for a living user who can log in. That single assumption shapes everything about how the app stores your work, who controls access to it, and what happens when the login stops working. Digital legacy planning asks the opposite question. It asks what happens when the person who knew the password is gone, when the account holder cannot approve a prompt, reset a code, or explain where something was filed. Judged on that question, familiar strengths can turn into obstacles, and features that look ordinary during life — a file you can copy, a page that opens without a network, an entry that stays sealed until the right person arrives — become the whole point.

This section goes through the note apps most people already use, one by one. For each, the test is specific to this scenario: an executor, a surviving spouse, or a trusted adult child needs, months after a death, to find instructions, locate accounts, understand wishes, and retrieve the documents that were meant for them, without breaking rules, begging a support desk, or guessing passwords at a kitchen table. VaultBook will not win every comparison that follows. It is not trying to. The claim is narrower and more practical: for custody and handover, a single local file with per-entry encryption gives the person you leave behind a door they can actually open, while a note locked behind someone else’s account gives them a wall they have to petition.

Notion

Notion has no built-in legacy-contact or inactive-account designation of its own. That is not an accusation; it is simply the shape of the product. A workspace sits behind the account login, and access flows from that login. While you are alive and able to share a page, invite a collaborator, or export a section, that model works smoothly. After a death, the same model leaves your executor on the outside of the account, looking at a login screen for a service that has no self-serve process by which they can step into your place. If you never shared the relevant pages in advance, and if the credentials to the account are not available through some other channel you arranged, the notes might as well be in a locked room in a building your family does not own.

Consider what that means for the material a legacy vault is meant to hold. A page listing your accounts, your advisers, the location of your will, and the instructions for your digital subscriptions is only useful if the right person can read it when you cannot hand it over yourself. In Notion, handing it over in advance usually means sharing it while you are alive, which exposes it during life, or leaving the account password somewhere else, which recreates the very problem the vault is meant to solve. The note and the key to the note end up depending on each other.

VaultBook breaks that circle by changing where the note lives. The vault is a single HTML file on your own machine. It is never uploaded to a company server, and it makes zero network requests when it opens. Custody is physical before it is digital: if you copy that file to a USB drive and hand the drive to your executor, or leave it with your attorney, the file is in their possession in a way a workspace on a remote server never is. There is no account to freeze, expire, reset, or delete between your death and the day they need it.

The encryption model matters just as much. VaultBook encrypts entries individually with AES-256-GCM, derived through PBKDF2 and handled with Web Crypto in the browser. That per-entry design lets you seal different material for different moments and different people. Your funeral preferences and a letter to your spouse can sit in entries governed by one arrangement, while a sensitive financial inventory sits in another, rather than forcing you to share an entire workspace to share one page. Notion’s sharing is generous and granular for living collaborators, but it is sharing inside an ongoing account. VaultBook’s sealing is designed for a handover that happens once, under sad circumstances, by someone who may never have used the tool before.

Offline reliability completes the picture. An executor opening the vault in a solicitor’s office, on an old laptop, or in a house where the broadband account has already been cancelled needs nothing but a browser. No login, no provider uptime, no two-factor prompt sent to a phone that has been returned or wiped. One file, copied to any machine, opened locally. For a legacy document, that boring reliability is not a minor convenience. It is the difference between instructions that survive the collapse of the household’s normal systems and instructions that depend on those systems still working.

Evernote

Evernote’s own terms are unusually clear about what happens after death or incapacity, and anyone planning around the app should take that clarity seriously. The company states a privacy pledge that continues after death or incapacity, and says it will not provide content to anyone, even next of kin, unless legally obligated to do so. It also tells users, in effect, that they must implement their own access process. Read fairly, that is an honest position: Evernote will protect your notes from other people, and arranging for the right person to reach them is your responsibility, not the company’s.

The trouble is that many long-time users mistake a decade of faithful syncing for a handover plan. Their most important notes — scanned letters, account summaries, household inventories, research for a family property — live in notebooks inside an account their family cannot open. The pledge that protected those notes during life now keeps them sealed in the wrong way: not sealed for a named executor with a passphrase you arranged, but sealed behind a policy and a login. Legal obligation is a high bar, and a grieving family should not have to discover, after the fact, that retrieving a parent’s own household notes requires a legal process they never anticipated.

VaultBook answers this scenario on custody first. Because the file never leaves your machine unless you choose to copy it, there is no provider standing between your executor and your instructions, and no terms-of-service conversation to have at all. You do not need a company to make an exception, because you never gave the company the only copy. That is the concrete meaning of no upload in this context: not a slogan about privacy in general, but the removal of a gatekeeper from a moment when your family has enough gates to deal with already.

Per-entry encryption then does the work Evernote’s account-level protection cannot do for handover. You can leave the vault file itself with more than one trusted person, because possession of the file is not the same as ability to read every entry. The entries that matter can stay encrypted until the passphrase arrangement you designed comes into play. During your life, that means a copy held by your attorney is not an open book. After your death, it means the same copy becomes readable exactly as far as you intended, and no further. Evernote users who built their own access process often end up sharing a master password on paper, which exposes everything at once. A vault organised entry by entry lets you be more precise than that.

There is also a practical matter of time. A legacy file may sit untouched for years before it is needed, and then sit in probate and family administration for months more. VaultBook does not require a living account on the other end of that wait. It opens in a browser, offline, on whatever computer is available, with version history inside the file preserving how entries changed. If you updated your instructions three times over five years, the executor is not dependent on a sync service having kept faith across all that time. The history travels with the file itself, because the file is the whole application and the whole archive at once.

Microsoft OneNote

OneNote cannot be separated from the Microsoft account that holds it, and Microsoft’s own support guidance sets the terms starkly. The company says it is generally unable to provide information to non-account holders. An Outlook or OneDrive account freezes after a year of inactivity and is deleted shortly afterwards; an account expires after two years; and access to content requires a valid subpoena or court order. There is no self-serve legacy designation by which you can name a person today and have Microsoft hand them your notebooks tomorrow. Put plainly, a OneNote notebook’s fate is the Microsoft account’s fate.

That timetable collides badly with real bereavement. Families do not always settle an estate in a neat year. A house sale stalls, a tax question drags, a relative abroad needs documents long after the funeral. If the notebook holding the household inventory, the insurance details, and the notes on a family business sits inside an account drifting toward a freeze, the clock is running on the very record meant to help. And the person best placed to stop that clock — the account holder, logging in periodically to keep the account alive — is precisely the person who is no longer there.

Against that, VaultBook’s lack of an account is not a missing feature. It is the mechanism of survival. There is nothing to freeze because there is no server-side account state. There is nothing to expire because the file does not live on a provider’s retention schedule. Your executor does not need to persuade Microsoft of anything, produce a court order to read your own instructions to them, or race an inactivity timer they may not even know exists. They need the file, which you already gave them or told them where to find, and the passphrase arrangement, which you designed while you could still explain it.

The one-file portability matters here in a very concrete way. A OneNote notebook feels portable to its owner, syncing happily between a desktop, a laptop, and a phone. But that portability is borrowed from the account; remove the account and the copies stop being a system. A VaultBook file’s portability belongs to the file itself. Copy it to a USB stick, a second computer, a disc in a document folder with your will — each copy is complete, opens in a browser without a network, and carries its encrypted entries with it. Redundancy, which is what a legacy record actually needs, is just copying a file. You can do it in an afternoon and test every copy yourself.

Per-entry AES-256-GCM encryption resolves the tension that stops many OneNote users from making those copies at all. A notebook full of sensitive instructions feels too exposed to duplicate widely, so it stays in one account, in one place, dependent on one login. In a vault, duplication does not mean exposure, because the sensitive entries are sealed individually. You can be generous with copies and strict with access at the same time — generous enough that the record survives a house fire or a failed hard drive, strict enough that a copy in a desk drawer is not a readable dossier on your family’s finances.

Google Keep

Keep lives inside the Google account, and that single fact decides its legacy story. Keep is where millions of people put the fragments that run a household: the gate code, the plumber’s number, the list of medications, the note about which neighbour has a spare key, the reminder about a parent’s appointment. Those fragments are exactly what a surviving spouse needs in the first fortnight after a death, and they are exactly what disappears behind an account login when the account holder is gone. Without a plan, a Google account may be deleted after two years of inactivity, taking Keep and everything else in the account with it.

Google does offer the Inactive Account Manager, and the honest part of this comparison — covered in more depth below — is that you should set it up. But its limits define what Keep can and cannot do for legacy. You can name up to ten contacts, choose an inactivity period of three, six, twelve, or eighteen months, and arrange for data downloads. Passwords are never handed over. A download, months later, is not the same as a spouse opening a note tonight. The fragments in Keep were written for immediacy, and a legacy route that delivers them as an archive after a long waiting period does not match the need they were meant to meet.

VaultBook is built to be opened at the moment of need, by the person standing in the kitchen who needs it. The file can already be on the family computer, on a drive in the document folder, in the executor’s hands. It opens offline, with no login and no waiting period, because there is no provider deciding when inactivity has lasted long enough. If the internet is down, if the deceased’s phone is locked, if the Google account is in dispute or simply unknown territory for the family, the vault still opens in a browser and still answers.

That immediacy does not require leaving everything readable. Keep’s model is all-or-nothing at the account level: get into the account and you can see every note; stay locked out and you can see none of them. VaultBook’s per-entry encryption gives a middle state that fits a household far better. The day-to-day entries a spouse needs — contacts, locations, instructions for the house — can be arranged for straightforward access, while entries holding financial credentials, private letters, or sensitive family information stay sealed under a separate passphrase arrangement. One vault can hold both the open door and the locked drawer, instead of forcing a family to choose between total exposure and total lockout.

Search deserves a mention here too, because a legacy record fails if the right entry cannot be found under stress. VaultBook includes search across the vault, including semantic question-and-answer search and OCR over scanned material, all running locally. An executor who does not know your filing habits — and why would they? — can ask for what they need rather than learning your notebook structure first. Keep’s search is fast, but it searches only for the person who can log in. A search box behind a wall helps the bereaved not at all.

Apple Notes

Apple Notes presents the most serious challenge to this article’s argument, because Apple is the one major platform that has built a real legacy mechanism. Legacy Contact lets you name a person who, with an access key and a death certificate, can reach much of what you leave in iCloud: photos, messages, notes, files, and backups. For a family deep inside Apple’s ecosystem, that is a genuine route, and later in this article it gets the credit it deserves. Setting it up is one of the steps in the weekend plan below, and nothing here argues against it.

But its exclusions draw the boundary of what it can do, and the boundary runs right through the material a legacy vault exists to hold. Legacy Contact does not transfer purchased media, which is a minor loss, and — far more importantly — it does not transfer iCloud Keychain: no passwords, no passkeys, no payment information. The credentials layer, the layer a survivor needs to close accounts, stop payments, retrieve statements, and deal with every service that was never inside Apple’s walls, is precisely the layer Apple’s process leaves out. Add two practical warnings: Apple cannot replace a lost access key, so the key your contact misplaces is gone for good, and the data made available is deleted three years from the first approval, so the clock starts whether the family is ready or not.

So the Apple Notes user faces a split inheritance. The notes inside Apple can flow, if Legacy Contact was set up and the key survived. Everything the notes point to — the bank outside the ecosystem, the insurer’s portal, the email account from another provider, the safe deposit box, the subscriptions, the instructions themselves if they were kept elsewhere — still needs a plan that Apple does not provide. Worse, many people keep their most sensitive list inside a locked note in Apple Notes and assume the legacy route covers it, without separating what transfers from what does not.

VaultBook covers the whole map because it never belonged to one ecosystem. The file sits on your machine, not inside a vendor’s cloud, and you decide what goes into it: the account inventory, the locations, the instructions, the names of advisers, the letters, and — appropriately arranged — the credential information that Apple’s process excludes by design. Per-entry encryption means that sensitive material can be sealed entry by entry rather than left dependent on one platform’s rules about what a contact may see. And the file outlives any three-year window, because there is no server-side approval starting a deletion clock. A copy made this year opens the same way in ten years, in a browser, offline, on a Windows machine, a Mac, or whatever the executor happens to own.

The two tools are not enemies, and the plan below uses both. Let Legacy Contact do what it does well inside Apple’s walls. Let the vault hold the map of everything — including the things outside those walls and the instructions for using the Apple route itself, such as where the access key is kept. An executor who opens the vault first learns, in your own words, that a Legacy Contact arrangement exists, who the contact is, and where the key lives. That is what a map is for: not replacing every road, but making sure the person travelling after you knows which roads exist.

Samsung Notes

Samsung Notes is tied to the Samsung account and device ecosystem, and it has no standalone legacy handover mechanism of its own. For the many people whose phone is a Samsung and whose notes have accumulated there for years — household lists, scanned documents, notes on parents’ care, records of conversations with builders and insurers — that tie is invisible during life. The notes are simply there, on the device, syncing within the ecosystem. The tie becomes visible only when the device is lost, locked, replaced, or left in a drawer after a death, and the family discovers that the notes’ home was never really the phone in their hand. It was an account and an ecosystem they may have no route into.

This is the quiet risk for a huge number of households, because Samsung Notes rarely feels like a system of record. Nobody sits down and decides to make it their legacy archive. It becomes one by accumulation, one useful note at a time, until the day someone else needs to know what is in it. At that point the absence of a handover mechanism stops being a missing menu item and becomes the whole story. There is no contact to designate, no process to invoke, nothing for an executor to apply to. The notes wait behind a device lock and an account the family does not control.

VaultBook’s answer begins with moving the record of consequence out of any device ecosystem before that day arrives. The important material — the inventory, the instructions, the account map, the wishes — belongs in a file whose home is wherever you put it: your computer, a backup drive, a copy with your executor. Because the file opens in any browser, the executor’s own device allegiance is irrelevant. They do not need a Samsung phone, a Samsung account, or your handset at all. A legacy record that requires the deceased’s exact phone to have survived, stayed charged, and stayed unlockable is a record built on luck.

Encryption per entry again does quiet, essential work. The reason people hesitate to extract important notes from a phone app is that a plain document feels exposed, so the extraction never happens and the phone remains the only home. In the vault, the entries that need protection are sealed with AES-256-GCM individually, so the copy you hand over is safe to hand over. And because there is no account attached, there is nothing for a provider to freeze or retire and no ecosystem upgrade, account migration, or device trade-in that can strand the file. It is an HTML file. It opens. For a document whose entire job is to be openable by someone else, years from now, on unknown equipment, that plainness is the feature everything else rests on.

Where the leaders are genuinely stronger

A case that only lists the other side’s weaknesses is a sales pitch, not advice, and legacy planning is too serious for sales pitches. Each of the apps above does something better than VaultBook, and some of those strengths matter in real households. Naming them honestly does two things: it helps you decide what to keep using alongside a vault, and it clarifies what the vault is actually for. VaultBook is not a replacement for the tools of a living, working, collaborating life. It is the record you build for the day those tools can no longer be opened by the person who set them up.

Notion is genuinely stronger wherever work is alive and shared. Live collaboration, shared workspaces, linked databases, projects that several people edit at once and comment on in real time — this is Notion’s home ground, and VaultBook does not compete there, by design. A legacy vault is deliberately not a team space. It is a considered record, written by one person or one couple, sealed where it needs sealing, and opened rarely. If your household runs a business, a renovation, or a family project with other people contributing daily, keep that work in Notion and enjoy how good it is at it. Just do not mistake a shared workspace for an inheritance plan, and copy the settled facts — the contracts, the account numbers, the final decisions — into the vault where they can survive the account that hosted the discussion.

OneNote is genuinely stronger for anyone whose thinking happens with a pen and inside Microsoft’s world. Its handwriting support, free-form pages, and deep integration with Microsoft 365 — meetings flowing from Outlook, documents from the rest of the suite, notebooks shared across a workplace — serve students, engineers, field workers, and anyone annotating diagrams or taking notes in rooms where typing is impossible. VaultBook is a text-and-entries tool; it will not replicate the feel of ink on a page or the connective tissue of a corporate Microsoft tenant. If your working notes live in OneNote and thrive there, they should stay. The legacy question is separate: extract the durable information an executor needs — accounts, policies, property records, instructions — into a form that does not share the Microsoft account’s fate, and let OneNote keep doing the daily work it does better.

Apple Notes, together with Legacy Contact, is genuinely stronger inside Apple’s own walls than anything a third-party tool can offer, and it deserves to be said plainly. The Legacy Contact flow is well designed: you name a person, an access key is generated, and after your death that person, with the key and a death certificate, can reach your photos, messages, notes, files, and backups through a considered process rather than a support-desk plea. For the family archive that lives in iCloud — years of photographs, message threads, documents — that flow transfers real things that matter, and no vault can or should try to duplicate your photo library. Use it, set it up, and store the key carefully. Its hole is specific rather than general: credentials are excluded, purchased media is excluded, the key cannot be replaced if lost, the data is deleted three years after first approval, and everything you hold outside Apple sits beyond its reach. A vault complements it by holding the map, the credentials arrangement, and the instructions for everything beyond those walls.

Google Keep is genuinely stronger at the moment of capture, and capture matters more than archivists like to admit. It opens instantly, it is already on the phone, it syncs everywhere without thought, and a thought jotted in a car park survives because the friction was near zero. VaultBook, opened deliberately and organised into entries, asks more of you in the moment, and for passing fragments — a name, a number, a fleeting list — that extra weight is a real cost. Plenty of good legacy material starts life as a Keep fragment, caught before it evaporated. The honest division of labour is to let Keep catch the fragments as it does so well, and to promote the ones with lasting consequence into the vault during a periodic tidy-up, rather than leaving them to accumulate inside an account your family cannot enter.

Evernote is genuinely stronger as a capture-and-archive machine with a long memory. Its web clipper remains the mature standard for saving pages, articles, receipts, and research exactly as they appeared, and a track record stretching back years means many users hold archives in Evernote that exist nowhere else, organised in notebooks refined over a decade. Its export in ENEX format is a real capability, and for thinning out a living research archive it does the job. VaultBook will not clip the web for you or absorb fifteen years of notebooks wholesale, and pretending otherwise helps nobody. What the vault does better is the final step Evernote’s own terms leave to you: giving the resulting record a custody and access arrangement that works after death. Export what matters, distil it into entries, and hold the distillation somewhere your executor can reach without asking the original service for permission.

The conclusion follows from the pattern rather than from loyalty to any product. Every strength above is a strength for the living user — collaborating, capturing, clipping, syncing, integrating. Every weakness that matters for legacy is the same weakness wearing different clothes: the record depends on an account, a provider, a device ecosystem, or a policy that was never designed to hand it to your family. VaultBook is better for the reader whose problem is custody and handover — not because the rivals are bad at what they do, but because what they do was never this. Keep using them for your life. Build the vault for what comes after it.

Failure modes: the sealed envelope, the hidden list and the unfinished binder

Most digital legacy arrangements do not fail because the person who made them was careless. They fail in one of three familiar shapes, and the shapes are worth studying because each one looks sensible on the day it is created. The envelope in the desk, the list hidden somewhere clever, the handsome binder with sections for everything — each is an act of love and responsibility. Each also contains a flaw that only reveals itself later, when the author is not there to compensate for it. A good arrangement is one whose flaws you have already rehearsed against, so this section takes the three classics in turn.

The sealed envelope is the oldest arrangement of all: the master password, or the list of passwords, written down and sealed in an envelope kept in a desk drawer, a safe, or a file marked for the executor. Its first flaw is staleness. Passwords change — banks force resets, services demand new credentials, two-factor methods move from one phone to another — and almost nobody reseals the envelope after each change, because life is busy and the envelope feels finished. Within a couple of years it can hold the old password to the email account, the superseded login for the bank, and earnest instructions for services the household cancelled long ago. Its second flaw is the opposite of staleness: the envelope is completely open to anyone who finds it. A burglar, a dishonest visitor, a curious relative — the envelope cannot tell an executor from an intruder, and it offers the whole of a digital life to whoever opens it, often years before it should be opened at all. An arrangement that is simultaneously out of date and totally exposed has failed in both directions at once.

The hidden list fails more quietly. Instead of an envelope, the list lives in an obscure file, an innocuously named note, a document buried in a folder structure only its author understands. The reasoning feels sound: it is hidden from thieves, yet findable by family who know to look. In practice, discussed again and again by people sharing household experiences online, the hiding place is forgotten by the very people meant to use it. In one recurring pattern from those discussions, a spouse had hidden the financial passwords precisely so they would be available in an emergency — and when the emergency mindset arrived, the spouse could not remember where the list had been put. The knowledge of the hiding place lived in one person’s memory and habits, and memory is the least reliable storage medium in any household. Sometimes the list is found months later by accident. Sometimes it is on the old laptop that was wiped and donated. A hiding place that depends on being remembered is not a location; it is a hope.

The unfinished binder is the most respectable failure and the most common among organised people. A folder, a spreadsheet system, a set of printed forms for accounts, policies, properties, and wishes — begun with energy, maintained for a season, then gradually abandoned because updating it is clunky. Every change means reprinting a page, amending a spreadsheet, cross-referencing a section. So changes stop being recorded, the binder drifts from the truth, and its very completeness becomes misleading: an executor trusts it because it looks thorough, and acts on information that quietly expired two moves and three password resets ago. The binder shape carries one further trap, the circular one. People quite reasonably want to record the password to their vault or password manager in the system itself — the master list inside the binder, the vault’s access password stored as an entry within the vault. It feels tidy. It is also useless at the exact moment of need, because the key to the room has been locked inside the room. Any arrangement where the means of access is stored behind the access itself collapses the first time someone else tries to use it.

Against each failure, the arrangement this article recommends has a specific answer, not a general virtue. Against staleness, the vault is a living file with version history: updating an entry takes a moment, the change is preserved rather than pasted over, and there is no envelope to reseal or page to reprint, so the cost of staying current drops to something a person will actually pay. Against total exposure, per-entry encryption means a found copy is not an open book — the file can be discovered, copied, even kept by several people, while its sealed entries remain sealed. Against the forgotten hiding place, the vault’s location is not hidden at all: it is stated in your will’s accompanying letter, told to your executor in person, and recorded with your attorney, because the file’s security comes from encryption rather than obscurity. The hiding-place problem dissolves when there is nothing to hide and nothing to remember except a plan that is written down in the ordinary paperwork of an estate.

Against the binder’s maintenance burden, a single searchable file beats a system of sections and printouts: you amend one entry, save, copy the file over your backups, and you are done. And against the circular trap, the rule is absolute and simple: the vault’s passphrase is never stored inside the vault. It lives in the separate arrangement described earlier in this article — split, held by different people, or lodged through a channel independent of the file itself — so that file, passphrase, and instruction meet for the first time in your executor’s hands, not before. Finally, rehearsal answers the failure mode underneath all three classics: none of them was ever tested by the person meant to use it. The envelope was never opened by the executor during the author’s life. The hiding place was never tried by the spouse. The binder was never worked through by anyone else. The vault arrangement insists on a rehearsal — your executor opens a copy, finds a named entry, and confirms the passphrase route works while you are still there to fix whatever does not. Every failure in this section survived because it was never rehearsed. Yours does not have to.

A one-weekend plan for your digital legacy

Everything in this article can be built in a single weekend, not to perfection but to working order — a vault that exists, an executor who has opened it, and platform arrangements that are switched on rather than intended. Perfection is the enemy here; a good arrangement finished on Sunday beats a beautiful one planned for a year. What follows assumes two days, a computer, your phone, and one conversation with the person you trust most. Adjust the order to your household, but do not skip the rehearsal on the second day. It is the step that separates a plan from a pile of good intentions.

1. Saturday morning: run the inventory sprint. Before building anything, find out what you have. Work through your email inbox, your banking app, your phone’s saved accounts, and a year of statements, and write down every account, policy, subscription, and service that matters: banks, investments, pensions, insurers, utilities, email, cloud storage, social accounts, domain names, loyalty schemes with real value, and the devices themselves. For each, note the provider, the account holder, how you log in, and what your family would need to do with it — close it, claim it, transfer it, or simply know it exists. Do not chase completeness down to the last newsletter login. The goal of the sprint is the map of consequence: everything with money, memory, legal weight, or a payment attached.

2. Saturday late morning: decide who does what. Name the people in the arrangement while the inventory is still in front of you. Who is your executor? Who would actually handle the digital side in the first fortnight — not always the same person, and that is fine. Who holds a copy of the vault? Who holds each part of the passphrase arrangement? Write these names into the plan explicitly, because an arrangement with unnamed roles is an arrangement nobody owns. If a conversation is needed before someone can be named — a sibling, an adult child, a friend steadier with computers than your spouse — have it today, briefly, rather than leaving them a surprise.

3. Saturday afternoon: build the vault. Create your VaultBook file and make the first entries from the inventory: the account map, the locations of physical documents and keys, the advisers’ names and numbers, the household instructions, your wishes, and the letters you want to leave. Work in order of importance, not tidiness — if the afternoon runs out, the entries that exist should be the ones your family needs most. Encrypt the sensitive entries individually as you go, so protection is part of the structure rather than a chore deferred to the end. Use the built-in password generator for any new credentials the process creates rather than inventing them on the spot. Save, and note the file’s location somewhere ordinary and findable.

4. Saturday evening: set the platform legacy tools too. The vault is the map, but the platforms hold territory of their own, and their tools should be switched on while your resolve is fresh. On Apple devices, set up Legacy Contact, generate the access key, and store that key where your contact can actually reach it — then record in the vault that the arrangement exists and where the key lives, remembering that the key cannot be replaced by Apple if it is lost and that Keychain credentials do not transfer. In your Google account, configure the Inactive Account Manager: choose your contacts, choose your inactivity period from the three, six, twelve, or eighteen month options, and understand that it delivers data downloads and never hands over passwords. Note any other provider’s process you discover along the way, and record each one in the vault so your executor learns from one place what exists where.

5. Sunday morning: finish the passphrase arrangement. Decide, concretely, how the sealed entries will be opened when you cannot help. Split the passphrase between holders, lodge a part with your attorney, or use whichever separated arrangement fits your family — but write the design down in the unencrypted instructions, store no part of the passphrase inside the vault itself, and check the circular trap one final time: nobody should need the vault open in order to learn how to open the vault. Test the arrangement yourself from a cold start, on a different machine if you can, opening the sealed test entry exactly as your executor would.

6. Sunday late morning: make and place the copies. Copy the vault file to the places you decided: the executor’s keeping, the attorney’s file, a drive stored with your paper documents, and your own backup. Because the sensitive entries are encrypted, copies are protection rather than exposure — each one is insurance against a lost laptop or a damaged drive. Check every copy opens. A copy that has never been tested is a rumour, not a backup.

7. Sunday afternoon: hand over, in person where possible. Give the executor their copy yourself, or sit with them while it is transferred, and talk through what the vault is, where the other copies live, and how the passphrase arrangement reaches them. This conversation is part of the technology. People act on plans they have heard spoken by the person who made them, and hesitate over mysterious files discovered in a drawer. Fifteen minutes of plain talk now will save your family days of uncertainty later.

8. Sunday afternoon: rehearse the opening. Watch your executor open the vault on their own device, find a named entry, and open a sealed entry through the passphrase route you designed. Do not guide them with knowledge only you have; if they get stuck, the instructions need fixing, and fixing them is the exercise. Note every stumble and repair it before the weekend ends. When they can open it unaided, the arrangement exists in fact, not just in intention.

9. Sunday evening: calendar the annual review. Put a recurring date in your calendar — a birthday, an anniversary, the start of a new year — to reopen the vault, refresh the inventory, update changed accounts and wishes, retest a copy, and confirm the people named are still the right people. An hour a year keeps the whole arrangement honest. The sealed envelope failed because it was never reopened; your vault succeeds because reopening it is a standing appointment rather than a guilty afterthought.

That is the weekend. It ends with less mystery in your household than it began with: a map that exists, copies that open, platforms set to help rather than hinder, and at least one other person who has already done, once, the thing they may one day have to do in grief.

Frequently asked questions

Should passwords go in a will?

No. A will becomes a public document when it goes through probate, and anything written in it — account details, passwords, private instructions — becomes available to anyone who obtains the probated will. Passwords also change far more often than wills are rewritten, so a credential in a will is likely to be both exposed and out of date. Keep the will for what it does well: naming executors, distributing assets, appointing guardians. Let it refer, if your attorney advises, to the existence of a separate arrangements letter or vault, and keep every credential inside the vault, where it can be sealed, updated, and kept out of public record.

Does VaultBook replace a password manager?

No, and the two tools do different jobs that fit together rather than compete. A password manager holds live credentials: it fills logins, syncs them between your devices, and is built for daily use by you. VaultBook is the map and the archive: the inventory of what exists, the instructions for what to do with it, the documents, the wishes, the letters, and the record designed to be opened by someone else after you. In practice, the vault records that the password manager exists, which one it is, and how your executor reaches the credentials through the arrangement you designed — while the manager itself keeps doing the daily work. Replacing a manager with a vault would make your daily life clumsier; replacing a vault with a manager would leave your family holding logins with no instructions, no context, and no map. Use both, each for its purpose.

What if the executor is not technical?

Then the arrangement should be tested against that fact, not despite it, and VaultBook was chosen for this role partly because the demand it makes is small: the executor needs to open a file in a browser, which is something anyone who has used the web has already done. There is no software to install, no account to create, no command line, no recovery ceremony. What a non-technical executor does need is instructions written for them — in plain language, in the unencrypted part of the vault, telling them what the file is, where the passphrase arrangement reaches them, and who to call for help. The rehearsal matters most here. If your executor opens the vault once while you are beside them, the second opening, whenever it comes, is a memory rather than a challenge.

What happens if the vault passphrase is lost?

Honesty matters here, because the answer is the hard edge of real encryption: entries sealed with a passphrase that is genuinely lost cannot be recovered. VaultBook cannot reset it for you, no support desk holds a spare key, and no back door exists — because a back door that could rescue you could also be used on you. That is the point of encryption, and any tool that promises otherwise is describing something weaker. The correct response is not to avoid encryption but to design the passphrase arrangement so that loss is unlikely: more than one holder, parts kept in more than one place, an attorney holding a component, and a rehearsal that proves the route works. Treat the passphrase with the seriousness you give the key to a safe deposit box, because functionally that is what it is.

Can one vault serve both spouses?

Yes, and for most couples it should. A household’s digital estate is shared in practice — joint accounts, shared subscriptions, one person’s name on a utility and the other’s on the insurance — so a single vault holding the whole map matches reality better than two partial files. Per-entry encryption is what makes sharing the file safe and sensible: entries belonging to one spouse’s individual affairs can be sealed separately from the household entries, and each spouse’s arrangements can be recorded distinctly inside the same structure. Agree together who else holds copies, how each of your passphrase arrangements works, and record in the vault what should happen if you die together or within a short time of each other, because executors ask that question and the middle of grief is the worst time to improvise the answer.

Is this legal advice?

No. This article is general information about organising your records and understanding platform tools, not legal advice about your estate. The law that governs digital assets after death — in the United States, the framework most states have adopted is RUFADAA, the Revised Uniform Fiduciary Access to Digital Assets Act — interacts with each platform’s own tools and terms, and the details vary by jurisdiction and by the choices you have made inside each service. Platform settings, terms, and procedures also change over time. An estate attorney in your own jurisdiction can tell you how your will, your platform designations, and your vault fit together, can hold part of the arrangement, and can make sure the plan you build this weekend says in law what you mean it to say. The weekend builds the record; the attorney makes it robust.

What about incapacity, not death?

Incapacity is the harder case, and the more common one. A stroke, an accident, dementia — these leave a person alive but unable to manage accounts, explain arrangements, or approve access, sometimes for years. Platform legacy tools are mostly built around death and its certificates; they may do nothing at all for a living, incapacitated account holder, which is one reason Evernote’s terms, notably, speak of incapacity alongside death when refusing to hand content to others. A vault arrangement can be designed to work here too: a copy already held by your spouse or attorney, a passphrase arrangement that can be activated by the people named in your power of attorney, and instructions recorded while you could still give them. Raise it explicitly with your attorney when you discuss the will, because the documents that authorise someone to act for you in life — powers of attorney and their equivalents — are the legal half of the same plan, and the vault is only the practical half.

Leave a door, not a puzzle

Strip away the platforms, the encryption, and the timetables, and what remains is a simple human fact: the work described in this article will be done by people who are grieving you. Your spouse, your child, your oldest friend — whoever carries your estate will carry it in the worst weeks of their year, at a table covered with paperwork, fielding calls from institutions, making decisions through exhaustion. Every digital arrangement you leave becomes, for them, either an hour saved or an hour added. A password reset fought for against a support desk is an hour of grief spent on a login screen. A note that cannot be found is an evening gone. A locked account holding the only copy of something precious is a small second loss laid on top of the first.

That is the ethical core of digital legacy planning, and it has nothing to do with technology enthusiasm. You are not organising files. You are deciding, in advance and in comfort, how much unnecessary pain the people you love will have to absorb in order to settle the practical shell of your life. The providers will follow their policies; the policies were written for the providers’ protection, and your family will experience them as indifference, because to a person holding a death certificate, a frozen account feels personal even when it is not. The only actor in the whole system who can be on your family’s side in advance is you. The vault, the copies, the passphrase arrangement, the rehearsal — these are simply what being on their side looks like in practice.

So leave a door, not a puzzle. A puzzle flatters the person who designed it; a door serves the person who has to walk through it. Do not hide your records cleverly, do not encase them in accounts nobody can enter, do not assume love will somehow substitute for access. Write the map. Seal what needs sealing. Put the file in trusted hands while your hands can still do the giving, and watch, once, while someone else opens it.

Start with the inventory this weekend. Not the whole polished system — just the list, made honestly, of what you hold and where it lives. That single document, begun on Saturday morning, is worth more than a decade of good intentions, and everything else in this article is only the work of giving it a safe home. Your family will thank you for it in the only way that matters: by having one less hard thing to do on the hardest days.