Mustafa ERBAY

Posted on Aug 30 Originally published at mustafaerbay.com.tr

Digital Legacy: A Plan for the Accounts You Leave Behind

#learning #uretkenlik

While writing a runbook for my own infrastructure, I noticed something: every line I wrote assumed the person reading it would be me. "If the certificate doesn't renew, look here." "The backup is on that disk." Notes to myself, all of them. But the moment a runbook is truly tested is the moment its author isn't at the keyboard.

Digital legacy struck me as a legal topic for a long time — wills, notaries, paperwork. It isn't. It's a design problem first: the companies behind your accounts have already picked a default on your behalf, whether or not you ever think about it. And most of those defaults aren't "someone will sort it out." They're a quietly running clock.

If you do nothing, there's already a plan

What surprised me most were the timers sitting in the companies' own documentation. Microsoft's support page on the subject is blunt: Outlook.com and OneDrive accounts are frozen after one year, with email messages and OneDrive files deleted shortly after, while Microsoft accounts expire after two years of inactivity.

Google draws a similar line: it reserves the right to delete a personal account and its data after at least two years of inactivity. It also gives examples of what counts as activity — reading or sending email, using Drive, watching a YouTube video, sharing a photo, downloading an app, running a search, and signing in to a third-party service with "Sign in with Google".

The conclusion I drew isn't a pleasant one, but it holds: if you leave no instructions behind, the thing administering your estate won't be your family — it will be a retention policy.

Apple: you press the key yourself

Of the three, Apple's approach strikes me as the most honest. With Legacy Contact, you choose in advance who may access certain data in your account after your death. Setting it up takes a device on iOS 15.2, iPadOS 15.2 or macOS Monterey 12.1 or later. The person you pick doesn't need an Apple Account or an Apple device — a small detail that matters to everyone whose sibling is on Android.

The heart of the system is the access key. Generated when you designate the contact, it's required for them to file a request later; Apple asks for both that key and your death certificate. Documentation requirements vary by country — in Japan, for instance, a family certificate is required instead of a death certificate. Requests go through digital-legacy.apple.com; once the request completes, Activation Lock is automatically removed from the devices, though the device still has to be erased and restored before reuse.

There's a sentence in the documentation that's easy to miss and, to me, the sharpest one: you can designate more than one Legacy Contact, and any one of them individually can make decisions about your account data after your death — including permanently deleting it. Naming two people adds resilience, yes. It also doubles the demolition rights. If it were me, I wouldn't make that choice by asking who's closest to me, but by asking who won't press an irreversible button in a moment of panic.

Apple's "most honest" quality holds for people who prepared in advance; without preparation the picture hardens. The same page notes that a death certificate is generally required, but that a court order or other documentation might be needed too. Without an access key the route leads straight to a court: in the U.S., Israel and some other locales access can be requested that way, only one person may request access to the account, and Apple states plainly that some data is end-to-end encrypted and it cannot decrypt it. In jurisdictions such as France, Germany, Japan, Australia and New Zealand, alternative documentation is accepted instead of a court order; Turkey isn't on that list.

Google: a counter that measures silence

Google's tool, Inactive Account Manager, works on different logic. Apple verifies death with a document; Google measures silence. If your account stays inactive for the period you choose, the plan triggers.

You can name up to 10 people, and you don't have to give them all the same thing — different data types can go to different people. One security detail I liked: Google asks for your trusted contact's phone number and uses it solely to verify their identity, so that someone who intercepts the email still can't download the data.

The activity measurement that decides when the plan fires matters here too. On this side Google spells out the signals it looks at: your last sign-ins, recent activity in My Activity, Gmail usage, and Android check-ins. Reading that list, the first thing that came to mind was this: a phone forgotten in a drawer but still signed in could delay the plan from triggering. Measured inactivity and real-life silence aren't the same thing.

The exceptions to the deletion policy come into play as well. Google says the two-year inactivity rule doesn't apply uniformly: accounts with an active subscription, a gift card holding a balance, a published app, a child account managed through Family Link, or a digital item purchased with the account (a book, a movie) are excluded. It sounds like a technical footnote, but the practical consequence is this: an account nobody can get into may survive for years precisely because its monthly payment keeps going through — along with a credit card quietly doing its job in the background.

Nobody is notified during setup; your trusted contacts receive nothing until the period you set has elapsed. When it does, an email goes out with the text you wrote, Google appends its own explanation underneath, and if you chose to share data, a download link comes with it. Let me also note the small caveat on Google's own page: some information can't be shared.

Microsoft: no handover here, just a calendar

Let me state it plainly: on the Microsoft side there is no legacy contact feature you can configure in advance. I too remembered the story still circulating online — that next of kin apply and Microsoft ships the contents on a DVD. I couldn't find any such promise on today's official support page. What the page describes instead is far colder: releasing account contents requires Microsoft to be formally served with a valid subpoena or court order, and each request is decided only after careful review.

The court route varies by geography as well: for customers in Europe, requests are served on Microsoft's Irish entity in Dublin. But the detail that matters most is this — two countries get an entirely separate door. Customers in Germany may contact Microsoft customer support directly to be granted access without going to court, providing a death certificate, the deceased person's ID, a certificate of inheritance (Erbschein) or other court documentation proving heirship, and the requestor's ID. A comparable support route is defined for China. Turkey is not among these privileged paths; it isn't named on the page at all.

If you do know the password, though, the page points you at a settings screen rather than a lawyer: you can close the account yourself. After closing it, signing back in within 60 days reopens it, because Microsoft holds the data for that window. And if nobody knows the credentials, the process runs on its own — the account closes after two years of inactivity.

I'd summarize Microsoft's model like this: with the password, the job ends on a settings screen; without it, you're looking at either a support request or a court order, depending on where you live. For someone reading this from Turkey, that means the second option.

The real gap: they hand over the data, not the keys

Laying the three documents side by side, this was the common thread that gave me pause. Apple's page explicitly lists what a Legacy Contact cannot reach: movies, music, books and subscriptions purchased with the account — and the data in iCloud Keychain, meaning payment information, passwords and passkeys. Google likewise notes that some information can't be shared.

That's not a coincidence; it's the design. These tools exist to deliver your data to your heirs, not to transfer your identity. The photos arrive, the emails arrive — but your bank, your insurance, your domain registration, your server panel, your child's school portal all keep their passwords in the vault. An heir holding ten years of photographs while the website disappears because the domain lapsed is standing exactly in this gap.

The most insidious version of this shows up if your vault is the platform's own password store: if your passwords live in iCloud Keychain, Apple's Legacy Contact mechanism is precisely what doesn't hand that data over. You can only close the gap at a vault layer you chose deliberately — and not every password manager has such a handover feature; if your product has no "emergency access" heading, your plan ends there. Bitwarden's emergency access defines two levels: view grants read access to the items in your vault, passwords and attachments included, while takeover lets your trusted contact create a new master password and permanently assume the vault — an action that replaces your old master password and removes your two-step login methods. The safety valve in between is the wait time: when a request arrives you can reject it during the period you set, and if the time lapses, access opens automatically. Worth noting that the feature requires a premium or paid organization plan.

If you haven't settled on a vault yet, the piece where I compared password managers across their open-source and commercial sides covers the recovery-mechanism half of that decision; this plan sits directly on top of it.

So who should hold this authority? It's tempting to reduce the question to "whoever is best with computers"; I used to do exactly that. Today I ask two things: can this person stay calm during the week I die, and are they patient enough not to use permanent-delete authority as a tidying reflex. Technical competence can be learned; those two can't. And don't forget to tell the person you chose: if the Apple access key never reached them, or you entered the wrong phone number for Google, the plan exists on paper and nowhere else.

The paper layer

Now we reach the point where the plan locks itself out. If your instructions live inside the vault, your heir has to have already opened the vault in order to read them. That's why one layer of the plan has to be non-digital.

The page I leave behind is short: which vault is in use and who holds emergency access, a physical copy of the Apple access key, a "close this first" list (recurring payments, domain renewals), and a list of what not to touch. I don't write passwords on it; if I did, the paper would become a vault, and vaults need locks. What I write down is where the lock is.

Two-factor authentication belongs on that page too. Whoever takes over the vault will stall at the second step on most accounts without recovery codes. In my comparison of 2FA methods I also called storing backup codes in a password manager reasonable; thinking through the succession scenario, I need to amend that advice in one place. Backup codes for your other accounts can live in the vault; your heir reaches them once they take it over. But the backup code for the vault's own second step cannot live inside the vault — if you don't keep that one outside, the person with the right to take over waits at the door.

A checklist you can finish in one afternoon

Designate a Legacy Contact on your Apple Account, print the access key, and confirm it reached the person.
Set up your Inactive Account Manager plan on Google: the waiting period, who receives which data, and the phone verification.
If you have a Microsoft account, set expectations accordingly: make sure the password is findable somewhere trustworthy, because the alternative is a support request or a court order depending on your country.
Configure emergency access in your password vault; decide deliberately between view and takeover, and on the wait time.
Keep the backup codes for your vault's own two-step login outside the vault; other accounts' codes can stay inside, but you can't put the code that opens the vault into the vault.
Write the page, tell one person where it is, and review it once a year — say, at tax time, when you're already in a bad mood.

Conclusion

Setting this up, I caught myself solving what felt like an engineering problem: single points of failure, delegation of authority, wait times, irreversible operations. Then I realized the real issue isn't technical. Apple verifies death with a document, Google measures silence with a counter, and Microsoft largely leaves the matter to the law; all three have chosen a default on your behalf, and none of those defaults were designed with the people you love in mind.

You can spend one afternoon replacing those defaults with your own choices. What you leave behind isn't a list of passwords; it's the amount of friction someone will meet during the worst week of their life.

DEV Community