Logistics Account Recovery: 4 Identity Signals for Continuity When Emails Change

Short answer: keep the account anchored to an internal identity record, then treat email as one replaceable recovery factor. For a logistics SaaS, that means a driver can rotate refresh tokens and revoke a stolen session without losing shipment history when their email address changes.

My recommendation is to model recovery as an identity decision, not an email-change endpoint. Store a stable subject identifier, version refresh-token families, and make every recovery action emit an auditable event. It takes a little more design up front. It also keeps a one-person team from repairing account merges by hand every Friday.

Why email continuity fails in a logistics account

Email is convenient because it is familiar and globally unique inside many systems. It is not a durable identity. Drivers change employers, dispatchers lose access to a company mailbox, and a contractor may use a personal address for one season and a fleet address for the next. A support agent who treats the address as the primary key eventually has to answer a frightening question: should this new address receive the old shipment records?

The dangerous shortcut is to overwrite users.email, send a link, and consider the account recovered. That flow proves control of an inbox. It does not prove continuity of the person, organization, vehicle assignment, or permissions represented by the old account. An attacker who controls a mailbox can pass that test too.

Keep these concepts separate:

• subject_id: an immutable identifier used by orders, driver payouts, and audit events.
• email: a mutable contact and notification channel, with verified and unverified states.
• credential: a password, passkey, or external identity binding that can be added or removed.
• session: a time-bounded authorization grant that can be revoked independently.

The distinction matters during a breach. If a stolen refresh token is accepted after an email update, the attacker keeps a valid path while the legitimate driver believes recovery is complete. The account may look healthy in the UI and still be compromised.

How should identity-centered account recovery preserve continuity beyond email addresses?

Start with an evidence policy. Write down which signals establish continuity, which merely increase confidence, and which are never sufficient on their own. A verified device key, a previously used passkey, an organization-admin attestation, and a recent successful login can be useful signals. A new email address is a notification destination until another signal binds it to the existing subject.

Use risk tiers instead of one universal recovery form. A low-risk change can require the current session plus a second factor. A lost-device flow can require two independent recovery factors and a cooling period before sensitive actions are enabled. A high-risk case, such as conflicting legal names and a changed organization, should stop automation and enter review. Your mileage may vary: the right cooling period depends on payout exposure, delivery data, and how quickly dispatch operations must resume.

The recovery transaction should be explicit and idempotent. Create a record containing the subject, requested changes, evidence references, reviewer or policy version, and an expiration time. Apply it once. If a client retries after a network timeout, return the same decision rather than creating a second identity or sending a second set of destructive revocations.

Make the record useful six months later.

For example, imagine a dispatcher whose company email is disabled on a Saturday while 40 trucks are mid-route. The dispatcher still has a registered passkey on a phone, but the phone's SIM was replaced during the move. A reasonable policy can accept the passkey plus a fleet-admin attestation, mark the new address as pending, revoke every refresh-token family issued to the old browser, and allow read-only dispatch access during the cooling period. A weaker policy accepts the new inbox immediately and leaves the old browser alive; that is how a routine HR change becomes an authorization incident. The exact signals and waiting period belong in a versioned policy document, because operations, legal requirements, and the value of the data change over time. Store the policy version with the decision so an investigator can reconstruct what happened without guessing which form a support agent used.

Do not merge accounts because two records share an email. Instead, require an authenticated link operation that names the source and destination subjects, shows the permissions that would move, and records who approved it. In many fleets, the safer answer is to keep two identities and transfer a narrow business relationship, such as a vehicle assignment, after verifying the operator with the fleet administrator.

Token rotation is containment, not proof of identity

Refresh-token rotation limits replay. It does not tell you who deserves access after a recovery request. Give each token family a server-side identifier and a generation number. On refresh, accept the current generation, issue a new token, and invalidate the prior one. If an old token appears again, revoke the family and all sessions derived from it.

The event stream should make that sequence visible:

type RecoveryEvent = {
  subjectId: string;
  kind: "email_change_requested" | "token_family_revoked" | "session_revoked";
  reason: "user_request" | "suspected_replay" | "admin_review";
  requestId: string;
  occurredAt: string;
};

function revokeCompromisedSession(subjectId: string, requestId: string): RecoveryEvent[] {
  const occurredAt = new Date().toISOString();
  return [
    { subjectId, kind: "token_family_revoked", reason: "suspected_replay", requestId, occurredAt },
    { subjectId, kind: "session_revoked", reason: "suspected_replay", requestId, occurredAt }
  ];
}

The production implementation must persist the revocation before confirming recovery to the user. It should also notify the old and new contact channels when policy permits, rate-limit attempts, and avoid revealing whether a subject exists. OWASP recommends generic authentication responses and careful handling of account recovery because messages can disclose account presence; its guidance is a useful baseline, not a complete policy for your fleet.

One hard lesson from the design review: never let a recovery success response imply that every device is trusted. Return a narrow status such as recovery_pending when a cooling period or review remains. Then make privileged operations check that state, rather than trusting a front-end banner.

A small test matrix catches the expensive failures

Build tests around transitions, not just endpoints. Seed a driver with two sessions, one active passkey, an old email, and an in-flight delivery. Then exercise these cases:

1. The driver changes email from an authenticated device. The subject and shipment ownership stay unchanged; the old refresh family is rotated.
2. A replayed refresh token arrives after rotation. The family and derived sessions are revoked, and no new token is issued.
3. The driver loses the device but presents two independent recovery factors. The new email remains pending until policy conditions are met.
4. Two subjects claim the same email. No automatic merge occurs, and the audit log records the conflict.
5. A retry repeats the same request_id. The result and emitted events are identical, with no duplicate transfer.

Instrument recovery latency, approval rate, token-replay detections, and manual-review volume. Watch for a rising approval rate paired with more post-recovery revocations; that combination suggests your evidence threshold is too low. Also log which signal made the decision, but avoid storing raw documents or secret values in ordinary application logs.

When a simpler email-only flow is the right choice

Identity-centered recovery is not suitable for a disposable newsletter account or a low-impact prototype with no durable user data. It adds state, policy reviews, and support tooling. If an account has no shipments, payouts, or organization permissions, a verified email link with short-lived sessions may be enough.

For a logistics product, though, continuity usually matters more than a frictionless address change. Choose the simpler flow when the business can tolerate account replacement and data loss. Stick with the identity-centered model when a wrong merge could expose delivery addresses, alter a payout, or put a driver back on the road under someone else’s credentials.

References

• https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• https://www.rfc-editor.org/rfc/rfc6819
• https://www.rfc-editor.org/rfc/rfc9449
• https://www.w3.org/TR/webauthn-3/