Every identity record is a photograph of a moving thing

Identity systems store attributes as though they were facts. They are observations with a timestamp, and almost nothing in the stack records the timestamp or reasons about it. The result is a stack that is simultaneously too trusting of old data and too eager to re-check data that has not changed.

The stranger in your text messages

Say you switch mobile carriers and get a new number. For the first week it is quiet. Then a verification code arrives for a food delivery account you have never opened. A few days later, a bank sends a one time passcode. Then a message from a dentist confirming an appointment for someone whose name you do not recognise, followed by a family group chat that has been running for eleven years and has just acquired you as a silent member.

You did nothing wrong. Neither did the carrier, which recycled a number that had been disconnected for the mandated waiting period, exactly as the system is designed to work. Neither, in any obvious sense, did the bank, which sent a code to the number on file, which was the number the customer gave them, which was correct at the time they collected it.

And yet you are now, from the point of view of a dozen online services, the account holder. Not because you attacked anything. Because a fact expired and nobody was watching.

This is not a thought experiment. Researchers at Princeton, Kevin Lee and Arvind Narayanan, sampled numbers that were available to new subscribers at two major United States carriers and found that a substantial share were still tied to the previous owner's online accounts, in many cases including accounts that would accept a password reset sent to that number. The Federal Communications Commission maintains a Reassigned Numbers Database precisely because this problem is well understood at the regulatory level, though it exists mainly to protect callers from liability under telemarketing rules rather than to protect account holders.

The interesting thing about the recycled number is not that it is a security hole. It is that it is a perfectly ordinary example of a category of failure that nobody has named properly, and that runs through almost every identity system in production.

What is identity decay?

Identity decay is the silent divergence between what a system believes about a person and what is currently true, caused by the passage of time rather than by any attack.

When you look at a star, you are not seeing the star. You are seeing light that left it years or millennia ago. The star may have moved. It may have changed colour. It may not exist. Nothing about the light tells you which, and the light is not lying to you. It is a faithful record of a moment that has passed.

Every identity attribute in every database you operate is that light. The address was correct when the utility bill was checked. The employer was correct when the offer letter was signed. The phone number reached the right person on the day the account was opened. Each record is faithful to its moment. None of them is a fact about the present, and the schema that stores them almost never says which moment they came from.

That last point is the whole problem. A system that knew an attribute was verified eighteen months ago could make a reasoned decision about whether eighteen months is acceptable for the thing it is about to do. A system that stores phone: +44 7700 900123 with no provenance cannot make that decision even in principle, because the information required to make it was discarded at write time.

Why decay is invisible

Most classes of data error announce themselves. A malformed record fails validation. A missing field throws. A corrupted value looks wrong. Decay does none of this. A stale phone number is a perfectly well formed phone number. A stale employer is a real company. A stale address is a real place where a real person lives, just not this one. Decay produces data that passes every check you have, which is why it survives every check you have.

It is also invisible in the aggregate. If ten percent of your customer phone numbers have been reassigned, nothing in your monitoring will surface that. The messages send successfully. The delivery receipts come back. The system reports health.

Why does a verified attribute become wrong without anyone noticing?

Three distinct mechanisms, which get conflated constantly and which need different remedies.

One: the world changes underneath the record

People move house, change jobs, marry, divorce, change their legal name, emigrate, and die. Nothing signals any of this to the institutions holding their records. The person themselves is usually the only party who knows, and their incentive to tell you ranges from weak to actively negative, since telling you generally means paperwork.

Two: the channel is reassigned to somebody else

This is the recycled phone number, and it is materially worse than the first category, because the attribute does not become empty. It becomes populated by a different human. An address that is out of date sends mail into a void, which is a privacy problem. A phone number that is out of date sends a password reset to a specific, identifiable stranger who now has a decision to make. Email addresses can behave the same way when a corporate domain is reissued or a provider recycles abandoned handles.

Three: authority is withdrawn while the record persists

The person is the same, their contact details are the same, and their right to act has ended. An authorised signer leaves the company. A professional licence is suspended. A power of attorney is revoked. An employee is terminated on a Friday and their name is still in the vendor master on Monday. This is the fastest and most consequential form of decay, and it is the one that connects directly to the fraud categories covered elsewhere in this series, including vendor bank change fraud and orphaned authority after offboarding.

How fast does each identity attribute decay?

The single most useful thing an identity architect can do is stop treating attributes as a homogeneous set. They decay at rates that differ by orders of magnitude, and the harm from staleness differs just as widely. A refresh policy that applies one cadence to all of them is guaranteed to be simultaneously too slow for some and pure waste for others.

Here is a working taxonomy. Treat the half life column as an ordering rather than a measurement, because the underlying population statistics vary by country, sector and cohort.

Read down the last column and notice how few rows call for the thing most institutions actually do, which is a full periodic re-verification of everything at once.

What does staleness actually cost?

It costs twice, and the second cost is the one nobody counts.

Failure one: acting on an attribute that is no longer true

This is the visible failure. A recovery code goes to a reassigned number and an account is taken over. A payment instruction is approved by someone whose authority ended last quarter. A background check clears a licence that was suspended in March. A benefit is paid to a person who died in January.

These losses are usually booked under other headings, which is why decay never appears in a risk register. The account takeover is filed as account takeover. The payment is filed as fraud. The benefit is filed as an improper payment. The common root, that a system acted on an attribute whose verification had expired, is not a field in anyone's taxonomy.

Failure two: re-verifying things that have not changed

The compensating control for the first failure is periodic review, and it is enormously expensive. A bank running customer due diligence refresh on a fixed cycle re-collects documents from a large population of customers, most of whom have changed nothing at all since the last cycle. Published per customer cost estimates for this work circulate widely in consulting material and vary so much that quoting one would be misleading, so treat the figure as unknown and the direction as certain: it is a large operating line, and the majority of the effort produces the answer "no change".

The customer pays too, in friction. Being asked to re-prove your identity to an institution you have banked with for a decade is not merely annoying. It is an abandonment risk, it falls hardest on people with unstable documentation, and it trains customers to hand over identity documents on request, which is the exact behaviour every phishing campaign relies on.

So the same missing capability produces both failures. Because systems store values without freshness, they cannot distinguish an attribute confirmed last week from one confirmed in 2019, and therefore cannot be selective. Having no ability to be selective, they choose between two bad policies: trust everything indefinitely, or re-check everything on a calendar.

Is identity decay the same as revocation?

No, and conflating the two is why most designs address neither properly.

Think about the two different ways food goes wrong. There is the date printed on the carton, which is a prediction about gradual deterioration. Nothing happens on that date. The milk does not receive a signal. It just becomes progressively less likely to be good, and the date is a reasonable place to stop assuming. Then there is a product recall, which is an event. A specific batch is declared unsafe at a specific moment, and the only thing that helps is a notification network that reaches everyone holding the product.

Decay is the date on the carton. Revocation is the recall. A printed date does not help you with a recall, because the deterioration is not gradual and the date has not passed. A recall network does not help you with ordinary spoilage, because nobody sends a notification when milk slowly turns.

Identity systems need both mechanisms and usually build neither. Revocation, and the specific failure of credentials that remain cryptographically valid after their status changed, is covered in credential zombies. This post is about the carton date: the gradual, unannounced, no signal case, which needs freshness metadata and cheap re-confirmation rather than a status list.

How would a freshness signal actually work?

Three components, none of them exotic.

First, attributes carry provenance. Every stored attribute gains two companions: when it was last confirmed, and by what method. Not when the row was updated, which is a database fact, but when a human or an authoritative source last asserted it, which is an identity fact.

Second, decisions carry a maximum acceptable age. Instead of a global refresh policy, each operation declares how fresh each input needs to be, proportional to what is at risk. Reading a balance might accept a phone number confirmed within two years. Sending a recovery code might demand ninety days. Changing a payout destination might demand a confirmation from the last few minutes, which is to say a signature on the action itself.

Third, confirmation is cheap. This is the part that makes the other two viable. If the only way to refresh an attribute is a full identity proofing ritual with document upload, then every policy will be set loosely, because tightening it would be unaffordable. If a person can confirm from an enrolled device in about five seconds, policies can be set by risk rather than by budget.

What the confirmation receipt contains

A confirmation is a signature over a small canonical object. The attribute is identified, not disclosed in full, and the signature covers what is being asserted and when.

{
  "type": "attribute_confirmation",
  "subject_key": "b7c1...9e4f",          // one way key for the enrolled human
  "attribute": "phone.primary",
  "value_hash": "sha256:41d0...aa72",    // hash, not the number itself
  "asserted": "still_current",
  "confirmed_at": "2026-09-25T09:14:02Z",
  "method": "device_signature",
  "valid_until": "2027-03-25T00:00:00Z"
}

The relying party stores the receipt next to the attribute. Anyone who needs to evaluate freshness later reads confirmed_at and verifies the signature against a published key, with no callback to the issuer and no lookup service in the path. The mechanics of verifying without contacting the issuer are covered separately in can you verify a credential without phoning the issuer.

The policy check

Once attributes carry timestamps, freshness stops being a background worry and becomes an ordinary precondition, expressed in the same place as every other authorisation rule.

MAX_AGE = {
  "send_recovery_code":    {"phone.primary": days(90)},
  "change_payout_account": {"signer.status": minutes(5)},
  "annual_statement":      {"address.postal": days(730)},
}

def allow(operation, subject):
    for attr, limit in MAX_AGE[operation].items():
        receipt = subject.freshest(attr)
        if receipt is None:
            return Deny("no confirmation on record", attr)
        if not receipt.verifies():
            return Deny("confirmation signature invalid", attr)
        if age(receipt.confirmed_at) > limit:
            return StepUp("confirm this detail", attr)   # seconds, not days
    return Allow()

Note the third outcome. A stale attribute is not a denial and not a silent pass. It is a prompt, aimed at the person who actually knows the answer, at the moment it matters, about the one attribute in question. That is a fundamentally different user experience from an annual demand to re-upload a passport, and it is also better security, because the confirmation happens in context.

A worked example

Picture a customer who opened an account in 2021 and has not been asked for anything since. They request a password reset in 2026. Under a conventional design, a code goes to the number on file, which may or may not still be theirs, and nobody will ever know which.

Under a freshness aware design, the reset operation declares that phone.primary must have been confirmed within ninety days. It has not been confirmed since 2021. The system does not send the code. It presents a confirmation step to the enrolled device, the customer signs, the receipt is written, and the reset proceeds with a phone number that was confirmed nine seconds ago rather than five years ago. If the customer no longer has the enrolled device, the flow becomes a recovery problem rather than a silent delivery to a stranger, which is the correct outcome and is dealt with in recovery without the ID upload.

What changes for the relying party

The operational shift is from a population wide calendar to a per attribute, per decision policy. That sounds like more work and is generally less, because the volume of full re-proofing collapses and is replaced by a much larger number of much cheaper confirmations, most of which take seconds and require no staff involvement at all.

It also changes what you can tell a regulator. "We refresh all customers every three years" is a statement about process. "No payout destination is changed on the strength of a signer record older than five minutes, and here are the receipts" is a statement about control, and it is verifiable by someone who does not trust you. The same shift, from process assertion to verifiable artifact, runs through workforce identity continuity and through cross border verification in trust across borders.

Honest limits

This is a design pattern with real gaps, and they should be stated plainly.

• Confirmation proves currency of an assertion, not truth of the attribute. A person who confirms that a phone number is still theirs has told you it is still theirs. If they are lying, or if a fraudster in possession of a stolen identity is diligently keeping it fresh, the receipt records a lie with a timestamp. Freshness is orthogonal to accuracy, and anyone who claims otherwise is selling something.
• Issuers mostly do not publish freshness metadata. Verifiable credential formats support validity periods, and SD-JWT based credentials can carry issuance and expiry claims, but there is no widely adopted vocabulary for "this specific attribute was last confirmed at this time by this method". That is a genuine gap and a reasonable target for standards work rather than for a vendor.
• Confirmation fatigue is real. A design that prompts constantly will be dismissed the way cookie banners are dismissed, and the confirmations will become as meaningless as the consent they replaced. Prompting has to be rare enough to remain meaningful, which means most attributes should never prompt at all.
• Agents must not be able to confirm on a human's behalf. If an assistant with account access can satisfy a freshness prompt, the entire mechanism evaporates, for the same reason set out in approval theater. The confirmation has to be produced on a device the agent does not control.
• It does not retrofit. Everything already in your database has no provenance and cannot acquire any retroactively. The best available move is to treat unconfirmed as its own state rather than pretending it is fresh, and to confirm opportunistically when a person is already present.

What to do this week

1. Pick your five highest consequence attributes. For most organisations these are the recovery phone number, the recovery email, the payout destination, the authorised signer list, and employment status.
2. For each, find out whether your schema records when it was last verified, as distinct from when the row was last written. In most systems the answer is no, and finding that out is the whole exercise.
3. Measure the age distribution of your recovery phone numbers. If a meaningful share were collected more than three years ago, you have reassigned numbers in your active population right now.
4. Check whether you consult a carrier reassignment source before sending anything sensitive to a mobile number. If not, that is a cheap and immediate improvement independent of anything else here.
5. Write down, for three operations of different value, the maximum acceptable age of each input attribute. Do it as an engineering exercise, not a policy exercise. The disagreements are the useful output.
6. Separate your revocation handling from your decay handling. If the only mechanism you have is an annual review, you have no revocation handling at all.
7. Audit your authorised signer and administrator lists against your leaver records from the last twelve months. Expect to find names. Everyone does.
8. Stop treating "confirm your details are correct" emails as a control. Nobody reads them, and an attacker in the mailbox reads them first.

If you want to see what a per action confirmation feels like from the person's side rather than the architect's side, the walk up demo takes under a minute, and the developer documentation covers the receipt format and the offline verification path.

Frequently asked questions

How often should identity information be re-verified? There is no single correct interval, because the right cadence depends on the attribute and on the value of the decision. Date of birth needs verifying once. A recovery phone number is worth confirming before any sensitive delivery. Authority to act should be established at the moment of the action rather than read from a stored list. Set policy per attribute and per operation, not per customer.

What is perpetual KYC? It is the shift from reviewing customers on a fixed cycle to reviewing them when something changes or when risk indicates. It is a clear improvement on calendar review, and it depends on having change signals to react to. Where those signals do not exist, perpetual review quietly becomes periodic review with extra reporting, which is why a cheap confirmation mechanism matters to making it work.

Why are recycled phone numbers a security risk? Because a disconnected number is reassigned to a new subscriber, and any account still using it for password resets or one time passcodes will deliver those to a stranger. Research from Princeton found a substantial share of numbers available to new subscribers were still linked to previous owners' accounts. The new holder does not need to attack anything to receive them.

Can someone confirm their details without full re-verification? Yes, and the distinction matters. Re-proofing establishes identity from scratch, usually from documents. Confirmation asserts that a previously verified attribute is still current, signed by the person on an enrolled device. Confirmation takes seconds, produces a verifiable artifact, and is appropriate for most refresh obligations that today trigger a full document check.

Is identity decay the same as credential revocation? No. Decay is gradual and unannounced, so it needs freshness metadata and re-confirmation. Revocation is an event at a known moment, so it needs a status mechanism that reaches verifiers. A system with only one of the two mechanisms will fail at the other, and most systems have neither.

Does a freshness receipt prove the attribute is true? No. It proves that a specific enrolled human asserted the attribute was still current at a specific time. That is strictly more than a database timestamp gives you and strictly less than verification against an authoritative source. For attributes only the person can know, such as which phone they still control, it is close to the best available evidence.

Sources

1. Kevin Lee and Arvind Narayanan, research on the security and privacy risks of number recycling at United States mobile carriers, Princeton University. recyclednumbers.cs.princeton.edu
2. Federal Communications Commission, Reassigned Numbers Database. fcc.gov/reassigned-numbers-database
3. NIST Special Publication 800-63, Digital Identity Guidelines, including the identity proofing model in 800-63A. pages.nist.gov/800-63-3
4. Financial Action Task Force, The FATF Recommendations, including Recommendation 10 on customer due diligence and ongoing monitoring. fatf-gafi.org
5. European Commission, anti money laundering and countering the financing of terrorism package, which moves supervision toward ongoing and event driven due diligence with obligations phasing in across the second half of the decade. finance.ec.europa.eu
6. W3C, Verifiable Credentials Data Model, including validity period semantics. w3.org/TR/vc-data-model-2.0
7. IETF, Selective Disclosure for JWTs and SD-JWT based Verifiable Credentials, for claim level timestamps. datatracker.ietf.org
8. FBI Internet Crime Complaint Center, public service announcements and annual reporting on account takeover. ic3.gov

Your database does not store facts about people. It stores light that left them a while ago, and it forgot to write down when.