Short answer: progressive profiling should update the record addressed by an immutable user ID, preserve verified identifiers as identities, and record each accepted change as a separately authorized, auditable state transition; it should never create a replacement user merely because a profile field or recovery address changes.
For a healthtech sign-up flow, that rule matters more than collecting every field on day one.
A patient may begin with an email and password, then add a display name, recovery method, or other application-owned attributes later.
The authentication record answers “who is this?” while the profile answers “what do we currently know about this user?” Combining those questions makes recovery dangerous: a changed email can accidentally become a changed person.
What does progressive profile retention actually cost?
The useful cost model is not a vendor price table.
It is the amount of state the team must retain, reconcile, authorize, and eventually delete.
Let be users, the mutable profile fields stored per user, and the accepted profile transitions.
Current profile storage grows roughly with ; the audit history grows with .
In a system where profiles change repeatedly, becomes the dominant retention term.
Provider calls and invoices still matter, but they aren't the hard part of explaining a patient's account history to a security reviewer.
One current row plus one immutable audit event per accepted transition is a tractable design.
The event needs the stable user ID, actor, time, operation, previous version, resulting version, and a correlation or idempotency key.
Sensitive values need not be copied wholesale into the event.
A field name, classification, and integrity-protected reference may provide the required evidence with less exposure; the exact retention period must come from the organization's legal and compliance analysis, not from a generic authentication recipe.
This changes the dominant term by separating operational state from evidence.
The current row stays bounded while the event stream grows predictably, so older events can move into a retention tier with stricter access instead of forcing every sign-in read through an ever-growing document.
Keep enough history to reconstruct authorized transitions and investigate account recovery.
Deliberately stop keeping password material, reset secrets, full request bodies, and redundant copies of sensitive profile values.
The catch is that aggressive minimization can reduce forensic detail when something goes wrong, so deletion schedules must be approved alongside incident-response and healthcare compliance requirements.
Short-lived recovery artifacts are different from identity history.
How should progressive profiling update a verified user without recreating identity?
Treat the user ID as the aggregate key.
Email is a lookup attribute and, once verified, an attached identity; it is not the primary key for profile writes.
Read the user by ID, authorize the requested transition, compare the caller's expected version, apply only allowed fields, and append the audit event in the same business transaction.
A stale request should receive a , a caller without the required privilege should receive , and a structurally valid but disallowed transition can receive .
Those are business-layer choices, not claims about a provider's response catalog.
The email-change path deserves its own state machine.
A request to replace a verified email should not overwrite it immediately or insert a second user.
Record a pending change, prove control of the new address, apply the verified transition to the existing user ID, and decide separately whether policy requires a notification or fresh authentication on the old channel.
Password-reset possession also must not silently authorize high-risk profile changes.
OWASP recommends consistent responses for password recovery requests so that the flow does not disclose whether an account exists.
Consider two concurrent updates that b