New signups versus migrations
A new pseudonymous signup can begin with an independently chosen identifier and fewer intended links, while a migration remains a review state until evidence establishes which older identifiers or relationships still matter. Neither label proves what a provider retained or whether two accounts are linked.
Not legal advice. This page is research, not compliance guidance.
New signups versus migrations
A new signup can use a newly chosen pseudonym for a new action, while a migration should be treated as a separate review state rather than proof that older identifiers, records, or recovery relationships were preserved or removed.
Compartmentalization and Pseudonymous Identifiers summarizes the accepted RFC 6973 evidence: pseudonyms or no identifiers can weaken the link between an individual and communications, and periodically creating new or randomized identifiers can reduce correlation across interactions. The same evidence says pseudonymity is strengthened when less personal data can be linked to a pseudonym, when that pseudonym is used less often and in fewer contexts, and when independently chosen pseudonyms are used more frequently for new actions.
Those statements support an intended new-signup baseline, not a guarantee about an account. A new label on an existing account does not establish a new signup. A newly chosen identifier does not establish that a provider has no older record. The accepted evidence describes generic correlation conditions; it does not describe a named provider's account model, migration behavior, retention, or recovery process.
A migration needs its own evidence entries because persistent or infrequently replaced identifiers can facilitate correlation over time. RFC 6973 gives device identifiers, certificates, and email addresses as generic examples. It also gives a separate generic example in which records from a context that does not authenticate users are matched with records from a context that does, making users in the first context identifiable. That example shows a possible correlation mechanism. It does not establish that a particular provider performed such a match or that two observed accounts belong to the same person.
The practical comparison is therefore between two evidence states. For a new signup, record the newly presented identifier and the intended lack of inherited relationships, then leave provider-held history unknown unless accepted evidence establishes it. For a migration, record the changed identifier, any older identifier or relationship actually observed, and the date and source for each observation. Do not convert the word migration into a finding about what persisted.
Start with an account that has no inherited recovery link
The intended baseline is a new action using an independently chosen identifier with less linked personal data and fewer reused contexts, while any inherited recovery relationship remains unknown until evidence establishes it.
Starting with no inherited recovery link is a baseline to test, not a fact supplied by the words new signup. The accepted RFC 6973 evidence supports using independently chosen pseudonyms more frequently for new actions and linking less personal data to each pseudonym. It does not establish whether a provider has an older record, whether an account was created rather than relabeled, or whether a recovery channel was carried forward.
Use Use a Privacy Vault as a Compartment Index as a bounded maintenance model. That reference includes a recovery-channel category, a legacy-link flag, and a last-review date among its seven maintenance fields. It also says to treat a flagged link as a review prompt rather than proof of identification or exposure. These are editorial recordkeeping fields, not a provider schema and not instructions from RFC 6973.
For the intended baseline, record the identifier presented for the new action, the recovery relationship actually configured or observed, and the date of that observation. If no accepted evidence addresses older provider records, write that state as unknown. An empty legacy-link field says only that no link has been recorded in that ledger; it does not prove that a provider holds no older identifier or that no other account can be correlated.
This boundary keeps the baseline useful without turning it into an anonymity promise. The evidence supports reducing intended reuse across contexts. It does not establish that the identifier is absent from every other context, that a recovery relationship cannot be matched, or that an observer lacks other records.
Record identifiers, authentication relationships, and recovery links separately
A migration ledger should give identifiers, authentication relationships, recovery links, provider records, and observed linkage separate entries because evidence for one state does not establish the others.
The accepted evidence describes more than one possible correlation mechanism. RFC 6973 says persistent or infrequently replaced identifiers can facilitate correlation over time. Separately, it gives a generic example in which logs from a context that does not authenticate users are matched with logs from a context that does. A ledger should preserve that distinction instead of reducing every possible relationship to a single linked label.
Record the current identifier as one state. Record an older identifier only when the evidence names or displays it. Record an authentication relationship as another state, with the context in which it was observed. Record a recovery relationship separately, including only what the accepted evidence establishes about the channel or category. Record any provider-held history as unknown unless a provider-primary or otherwise accepted record expressly establishes it. Finally, record observed linkage only when the evidence actually shows a match; do not infer it from a shared label or from the existence of a migration.
A useful entry can carry seven parts: the provider or system being observed, the action classified as signup, identifier change, or migration, the current identifier, any older identifier or record actually observed, the authentication relationship actually observed, the recovery relationship actually observed, and the observation date with its supporting source. Add a known-limit note when the evidence does not reach provider retention, account ownership, or linkage. These labels are an editorial recording method, not a claim that providers expose the same fields.
Use a Privacy Vault as a Compartment Index supplies the maintenance boundary. Its legacy-link flag and last-review date make a possible connection visible for later review, but a vault entry cannot undo persistent identifier reuse. The same reference says a flag is not proof of identification or exposure. The ledger therefore records why a relationship deserves review without upgrading that prompt into a finding about who owns an account or whether an observer matched records.
Why older persistent identifiers remain a review question
An older persistent identifier remains a review question because persistent or infrequently replaced identifiers can facilitate correlation, while the accepted evidence does not establish whether a particular provider retained or reused one.
A changed display name or current identifier does not answer the persistence question. The accepted RFC 6973 evidence says persistent use of the same device identifier, certificate, or email address across multiple interactions can allow recipients or observers to correlate communications over time. That statement supports checking for continued reuse. It does not support saying that an older identifier still exists in a particular provider's records.
The review should ask what was observed, where, and when. If an older identifier appears on an accepted record, name that record and its observation date. If a recovery category or authentication relationship repeats across intended compartments, record the repeated item as a review prompt. If the evidence shows only the current identifier, preserve the older-record question as unknown rather than assuming either deletion or retention.
Pseudonymity is strengthened under the accepted evidence when less personal data can be linked to the pseudonym, when the pseudonym is used less often and across fewer contexts, and when independently chosen pseudonyms are used more frequently for new actions. These are conditions that can guide review. They are not a necessity test that proves pseudonymity failed whenever one condition is absent, and they are not evidence that a named provider joined two records.
The durable conclusion is narrow: continued reuse can permit correlation, so an older persistent identifier deserves a dated check. The result of that check must stay attached to the observed system and source. A generic possibility cannot be promoted into a provider-specific history, and a recorded legacy-link flag cannot be promoted into proof of identity.
Maintain a dated migration and legacy-link ledger
Maintain the migration record as dated observations of one named system, keeping a possible legacy link visible for review without treating the flag as proof of identification, exposure, retention, or account ownership.
A dated ledger makes later comparison possible without rewriting an earlier unknown as a fact. For each observation, keep the system name, the action category, the identifier shown, any authentication or recovery relationship actually observed, the evidence locator, the observation date, and a limit statement. When an item is not established, preserve it as unknown rather than filling the field with an assumed provider behavior.
The maintenance model comes from Use a Privacy Vault as a Compartment Index, observed in the accepted published record dated 2026-10-05. That reference records seven maintenance fields, including a recovery-channel category, legacy-link flag, and last-review date. It also states that a vault entry cannot undo persistent identifier reuse and that a flagged link is a review prompt rather than proof. Those limits travel with the model whenever it is applied here.
The generic correlation evidence was captured from RFC 6973 on 2026-10-03. A later review can re-check the accepted source and the system being observed, but the earlier entry should retain its own date and wording. This prevents a later identifier change from silently erasing what was observed before it, and it prevents an earlier possibility from being restated as a later finding.
No universal review interval is established by the accepted evidence. A next-review date is an editorial maintenance choice, not a provider rule or a prediction about when records change. Private Pierce methodology explains the site's use of dated sources, evidence boundaries, and explicit non-findings.
Limits and non-findings
This reference does not establish named-provider migration behavior, retained or deleted records, inherited recovery links, observed account linkage, account ownership, a universal migration sequence, or a universal review interval.
The RFC 6973 evidence establishes generic conditions and examples. It says that periodically creating new or randomized identifiers can reduce correlation, describes conditions that strengthen pseudonymity, and explains that persistent identifiers and cross-context record matching can facilitate correlation or identification. It does not establish that a named provider retained an older identifier, matched logs, migrated an account, or linked two accounts.
The vault evidence establishes an editorial maintenance model. A recovery-channel category, legacy-link flag, and last-review date can preserve a question for later review. The model is not a provider schema. An unflagged entry does not prove that no legacy relationship exists, while a flagged entry does not prove identification, exposure, compromise, ownership, or an observed match.
No accepted evidence establishes a universal sequence for migration, a point at which an older provider record ceases to matter, or the result of deleting or changing an identifier. No accepted evidence establishes that a recovery relationship is inherited during migration. No person-specific example or live-account test supports this reference.
The supported use is narrower: distinguish the intended new-signup baseline from the migration review state, record each observed identifier or relationship separately, attach a date and source, and preserve every unsupported provider-specific outcome as unknown. That approach keeps the comparison answerable without converting a generic privacy mechanism into a claim about a particular account.
Frequently asked questions
What is the difference between a new pseudonymous signup and an account migration?
A new pseudonymous signup can begin with an independently chosen identifier and fewer intended links. A migration is a separate review state; the label alone does not establish whether older identifiers, provider records, authentication relationships, or recovery links remain.
Does changing an account identifier remove older provider records?
The accepted evidence does not establish that result. Record the current identifier and leave older provider records unknown unless accepted evidence for the named system establishes their state.
Can an inherited recovery link reconnect a pseudonymous account?
A repeated identifier or cross-context match can permit correlation in generic terms, but the accepted evidence does not establish that a recovery link was inherited or that two particular accounts were connected.
What should a migration ledger record?
Record the named system, action category, current identifier, any older identifier actually observed, authentication and recovery relationships actually observed, observation date, supporting source, and known limits.