The safest account to steal is one nobody has opened in four years

Fraud models are trained on activity, which means they are blind exactly where the money sits unwatched. A dormant account has a recycled phone number, an expired recovery domain, and a password in six breach dumps, and nobody is looking at it. Safe reactivation has to prove the same person came back, or admit that it cannot.

Consider an email address somebody set up in 2011 for a university course, used heavily for two years, and then abandoned when they moved to a new provider. It still exists. Nobody has opened it since roughly 2015.

It is also, quietly, the most valuable thing that person owns online, and they have no idea.

That address is still the recovery contact on an old brokerage account holding a few thousand in a fund nobody rebalances. It is the registrant contact on a domain that still points at a small business site. It is the backup email on a loyalty account with a decade of accumulated points. It is listed in the account recovery settings of three services the person uses every single day, because when they set those up in 2016 they typed the address they had always typed.

The password to that email account was breached in 2013, again in 2016, and again in 2019, and appears in corpora that anyone can download. The phone number attached to it belonged to that person until 2018, when they changed carrier and let it lapse, and it now belongs to a stranger in another city who has had it for years.

Nobody is watching this account. That is not an oversight in the security programme. It is the definition of dormancy, and it is what makes the account attractive.

Why is a dormant account the easiest one to steal?

Almost every fraud control in production assumes a specific thing about the world: that there is an owner who will notice. Anomaly detection assumes a baseline of normal behaviour to deviate from. Notification emails assume somebody reads them. Step up authentication assumes a legitimate user is present to complete it. Dispute processes assume a customer files one.

A dormant account violates every one of those assumptions simultaneously, and it does so silently.

There is no behavioural baseline, because there is no behaviour. The notification goes to an address that either bounces or belongs to somebody else. Nobody completes a step up because nobody is trying to log in. And critically, nobody files a dispute, which means the takeover never enters the statistics.

That last point deserves emphasis because it explains why this problem is neglected rather than solved. Security budgets are allocated against measured losses. Measured losses come from complaints. Complaints come from people who noticed. A category of attack whose defining characteristic is that the victim is not looking will be systematically under counted in every dataset the industry uses to decide what to work on, including the excellent ones. The FBI's Internet Crime Complaint Center reported more than $262 million in account takeover losses across over 5,100 complaints in 2025 (IC3 public service announcement, 25 November 2025), and complaint driven figures like that are a floor rather than a measurement, because the numerator is people who realised.

So the honest position is that nobody knows how large this is. That uncertainty is itself the finding, and any vendor who quotes you a confident dormant account fraud number is quoting you something they cannot support.

What is factor decay?

Here is the concept the rest of this piece rests on, and it is simple enough to state in a sentence: every authentication and recovery factor attached to an account gets weaker with the passage of time, without anybody touching it.

This is unintuitive because we tend to think of security properties as static. You set up two factor authentication, and you think of the account as protected in the way a locked door is locked. But the factors are not properties of the account. They are pointers to things in the world, and the things in the world change ownership, expire, and leak. The pointer stays exactly where it was while the thing it points at becomes somebody else's.

A useful way to picture it: an account's security is a set of addresses written on a card in a filing cabinet. The card does not change. The buildings at those addresses get demolished, rebuilt, and sold to other people. Ten years later the card looks pristine and every address on it leads somewhere unexpected.

The recycled phone number

Mobile carriers reissue numbers after a disconnection period, which is a sensible use of a finite resource and also means that a number that was your second factor in 2018 is somebody else's number today. Researchers at Princeton examined numbers available to new subscribers at major United States carriers and found that a substantial share were still linked to accounts on popular online services, meaning the new subscriber could receive password reset codes for the previous holder's accounts without doing anything at all. The new holder is not an attacker. They are simply a person who was assigned a number and who now receives somebody else's verification codes.

Notice the shape of this: no system was breached, no password was cracked, and the second factor worked exactly as designed. It delivered a code to the number on file. The number on file was correct. It just did not belong to the customer any more.

The expired recovery domain

The enterprise version is worse, because it can be acquired deliberately. An organisation used a domain for a project, a brand, or an acquisition, and let it lapse. Accounts created with addresses at that domain still list them as recovery contacts. Anyone can register an expired domain, stand up a catch all mailbox, and begin receiving password resets for every account that still points there. This is not a theoretical attack, it is a well documented pattern, and it costs the attacker a registration fee.

The password nobody rotated

A password set in 2013 and never changed has had a decade of opportunity to appear in breach corpora, and it very likely has, along with the email address it accompanied. For an account with no other protection, credential stuffing against a dormant account has a higher success rate than against an active one, because active users have been prompted to rotate, have adopted a password manager, or have enrolled a second factor in the intervening years. The dormant account is a snapshot of that person's security practice from the year they stopped caring about it.

The compounding effect is what makes this dangerous rather than merely untidy. It is not that one factor decayed. It is that all of them decayed together, in the same direction, over the same years, on an account nobody was watching.

Why is a dormant email account worse than a dormant bank account?

Most coverage of dormant accounts focuses on what the account contains. That is the wrong axis. The right question is what the account unlocks.

A lapsed brokerage account contains money, which is bad to lose. A lapsed email account often contains nothing of value at all, and is far more dangerous, because it sits at the root of the identity graph for accounts that are still active and still funded. Compromising it does not directly yield anything. It yields the ability to reset everything downstream that still trusts it.

People consistently underestimate this because the value is not in the asset, it is in the edges. When you set up an account in 2016 and typed a familiar recovery address, you created a dependency that has outlived your memory of it. Nobody maintains a list of which services point at which recovery address, so nobody can see the graph, which is the same visibility failure we describe in the authority graph, arriving through the consumer door instead of the enterprise one.

Ranking by what the account unlocks rather than what it holds reorders the list considerably, and it puts the account nobody thinks about at the top.

Why does re-verification on reactivation not fix it?

The standard institutional answer is to flag dormancy and re-verify on reactivation. This is a reasonable instinct and it fails for two distinct reasons that are worth separating.

The first is that re-verification usually means re-proofing through the contact points already on file, which are the precise things that decayed. Sending a code to the number of record, when the number of record was recycled three years ago, is not a check. It is a delivery. The institution experiences it as a successful verification because the code came back, and from the system's point of view nothing anomalous occurred.

The second is subtler. When an institution does escalate to document verification, it is asking the returning user to prove who they are, not to prove that they are the same person who held this account. Those are different questions, and the first one is answerable by anyone holding a stolen identity package, which is abundant, and increasingly by anyone able to feed synthetic imagery into a verification pipeline, which is the attack class we cover in the piece on injection attacks against identity verification.

So the escalation path leads from a weak check to a differently weak check, and both of them feel rigorous to the institution running them. We call the general form of this Recovery Debt, and dormancy is Recovery Debt compounded by time: the longer the account sleeps, the weaker every attached factor becomes, and the fewer options the institution has left.

There is a third failure that is more about incentives than mechanism. Fraud teams are measured on friction and on approved good customers, and a returning customer after four years is a retention win. The institutional reflex is to help them back in. Nothing in that reflex is wrong, and it is worth naming, because a control that fights the commercial incentive will lose unless it is designed to be quick for a genuine returner.

What would safe reactivation actually look like?

The reframe that makes this tractable: stop asking "is this person who they claim to be" and start asking "is this the same person who held this account". Those questions need different evidence, and conflating them is why reactivation flows are weak.

Identity proofing establishes a person from external documents. Continuity establishes sameness against something the account already knows. A dormant account's contact points have decayed, but a cryptographic key held by the original human has not, because keys do not get recycled by carriers or expire off a registrar's books. If a key was enrolled while the account was active, the reactivation check becomes a signature challenge, and either the returning human can produce it or they cannot.

The design that follows is graduated rather than binary, because reactivation requests vary enormously in risk.

result = reactivate.check(account_id)

if result.continuity == "enrolled_key":
    # signature from a key bound while the account was active
    allow_full_restore(receipt = result.receipt)

elif result.continuity == "companion_liveness":
    # face match on device against the enrollment-time one-way key
    allow_with_cooling_period(days = 3, receipt = result.receipt)

else:
    # account predates enrollment: no anchor exists
    open_as_new_relationship(
        transfers_blocked_until = "+14d",
        beneficiary_changes     = "staffed_review",
        note = "resumption unproven; treated as new anchor"
    )

The third branch is the important one and it is the part most designs get wrong. When there is no anchor, the correct behaviour is not to guess and not to refuse. It is to be explicit: this event is a new relationship rather than a proven resumption, and privileges that depend on continuity, such as moving an existing balance or changing a beneficiary, do not transfer immediately. The account holder gets their access back. The attacker gets an account with a fourteen day wall in front of the only thing they wanted.

That asymmetry is what makes the design work. A genuine returning customer, who waited four years, is rarely harmed by waiting a further two weeks before moving the balance, and is told clearly why. An attacker's economics depend on speed, because their window is bounded by the moment somebody notices. Time is the one factor that does not decay, and it is free.

The honest problem with accounts that predate everything

It would be dishonest to present continuity as a general solution, because the accounts most at risk are precisely the ones with no key to check against. An account dormant since 2015 has no enrolled credential, no device binding, and no anchor of any kind. No technology can prove sameness where nothing was recorded.

What can be done is to make the absence explicit rather than letting it pass silently. Today a no anchor reactivation and a fully proven one look identical in the record: both are a customer who logged in. Marking the difference, and attaching a signed receipt describing what evidence was and was not available, converts an invisible risk into a visible one that can be policy managed, reported, and reviewed after the fact when a dispute arrives.

The second thing that can be done is to stop the population growing. Every account being opened today can be anchored now, at a cost of nothing, so that in 2033 it is a solvable case rather than another legacy one. Institutions have been making this trade badly for two decades by treating enrollment as a cost rather than an asset that appreciates.

Honest limits

• No anchor, no continuity. For accounts predating enrollment, this makes the gap explicit and does not close it. That is a real limit and it applies to the majority of currently dormant accounts.
• Legitimate returners are inconvenienced at the worst moment. Someone coming back after a bereavement, a long illness, or a period abroad is least equipped to complete a check, so a staffed path must exist and must be treated as a normal route rather than a failure state.
• Heirs and executors are a genuinely hard case that continuity cannot serve, because the person entitled to the account is by definition not the person who held it, and the correct answer there is legal process rather than cryptography.
• Cooling periods have a real cost. Delaying a transfer for a genuine customer with an urgent need is a harm, and any institution deploying this should measure it rather than assume it away.
• Account deletion is a competing strategy with its own hazard. Reclaiming an abandoned identifier can hand the next holder the previous holder's inbound recovery links, which is the recycled number problem wearing different clothes.

What to do this week

If you are a person with old accounts, which is everybody:

1. List every email address you have ever used and check which ones you can still log into. The ones you cannot are the urgent ones.
2. For each active account that matters, look at the recovery settings and check what address and phone number are actually listed. Most people find at least one pointer to something they no longer control.
3. Update or remove every stale recovery pointer, starting with financial and email accounts, and prioritise removing a decayed pointer over adding a new one.
4. Check your old addresses against a breach corpus such as Have I Been Pwned, and treat any account still using a breached password as already compromised.
5. Do not simply abandon accounts you no longer want. Close them properly, because an abandoned account keeps its edges and a closed one does not.

If you run an institution holding dormant accounts:

1. Count them. Segment by dormancy age and by what each account unlocks rather than what it holds, and expect the number to be larger than anyone estimates.
2. Audit your reactivation flow honestly. Trace exactly which factors it relies on and ask which of them decay. If the answer is all of them, you have found your finding.
3. Separate resumption from re-proofing in your policy language, because the two are currently conflated in most procedures and the conflation is where the weakness lives.
4. Introduce a graduated no anchor path with a cooling period on value movement and beneficiary changes, rather than a binary approve or decline.
5. Anchor every new account from now on, so the dormant population of the 2030s is tractable.
6. Record a signed receipt for every reactivation decision, describing what evidence was available, so the eventual dispute has an artifact rather than an inference.

The account recovery demo shows the continuity check in practice, and the developer documentation covers the signing and verification calls.

Frequently asked questions

Can someone take over my old inactive account? Yes, and it is easier than taking over an active one. The password is more likely to appear in breach corpora, the phone number may have been recycled to a new subscriber who receives your reset codes, and the recovery email domain may have expired and been re-registered. Crucially, nobody is watching, so a takeover produces no complaint and often goes unnoticed for years.

What is a ghost account? It is an account that still exists and still has authority but has no active owner watching it: an abandoned email address, a former employee's unrevoked SaaS login, a lapsed brokerage account, or a registrar account controlling live DNS. The defining property is that a compromise generates no signal, because the person who would raise the alarm is not present.

How do banks verify a customer reactivating a dormant account? Most send a code to the phone or email of record, and escalate to document verification if that fails. The weakness is that the contact points on record are precisely what decayed during dormancy, and document checks prove who somebody is rather than that they are the same person who held the account. Those are different questions.

What is factor decay? It is the observation that every authentication and recovery factor attached to an account weakens over time without anyone touching it. Phone numbers are recycled by carriers, recovery domains expire and can be re-registered by anyone, and passwords accumulate in breach corpora. The account's settings stay unchanged while the things they point at change hands.

Why are dormant accounts a bigger fraud risk than active ones? Because fraud controls assume an owner who notices. Anomaly detection needs a behavioural baseline, notifications need somebody reading them, and disputes need somebody filing them. A dormant account defeats all three at once, and the resulting losses are under counted in complaint driven statistics, which is why the category receives little budget.

Should institutions just delete dormant accounts? Deletion reduces the target but creates its own hazard, because reclaiming an identifier can hand the next holder inbound recovery links belonging to the previous one. That is the recycled phone number problem in another form. Closing accounts properly, including removing their edges to other services, is safer than reassigning the identifier.

Sources

1. FBI Internet Crime Complaint Center, public service announcements including the November 2025 alert on account takeover fraud. https://www.ic3.gov/PSA
2. FBI Internet Crime Complaint Center, annual Internet Crime Reports. https://www.ic3.gov/AnnualReport/Reports
3. Princeton University, research on the security and privacy risks of phone number recycling at US mobile carriers. https://recyclednumbers.cs.princeton.edu/
4. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator binding and recovery. https://pages.nist.gov/800-63-3/sp800-63b.html
5. FFIEC IT Examination Handbook InfoBase, on authentication and account management in financial institutions. https://ithandbook.ffiec.gov/
6. National Association of Unclaimed Property Administrators, on dormancy and escheatment. https://unclaimed.org/
7. Have I Been Pwned, breach corpus for checking exposed credentials. https://haveibeenpwned.com/

Time is the only factor that never decays, and it is the one attackers cannot afford.