Identity Lifecycle and Recovery

An account system answers "what if I lose access?" with a password reset email. ClearDNS has no email to reset, so it answers the question differently. The recovery contract is easiest to understand by scenario.

The underlying principle: continuity lives in the durable policy/device bindings and, for app-store subscriptions, in the store subscription itself; everything else (sessions, invitations, cached artifacts) is temporary and replaceable by design.

Scenario 1: a dashboard session is lost#

Browser sessions are designed to be short-lived. If a session expires, the browser is closed, or browser storage is cleared, nothing durable is lost.

A device that is still legitimately using the policy authenticates again: the dashboard creates a new pending session, the device's DNS path proves the policy/member/device relationship, and a fresh session is bound. Losing a session never endangers the policy, because the session was never the identity; it was temporary administration state.

Accountless Dashboard Authentication

Scenario 2: one configured device is lost#

If a phone, laptop or router configured with ClearDNS is lost, an authorized member on a remaining device can remove that device from the policy through the dashboard.

What removal changes:

• until it is removed, the lost device's resolver configuration keeps working; possession of a valid configuration is exactly what the resolver authenticates;
• removal is an authority change in the backend binding state: after it, the resolver stops granting normal service to that binding, even though the configuration bytes still exist on the lost device;
• the removed device's slot can then be reused through normal enrollment.

This is why the reference describes binding authority as current backend state rather than something baked into the configuration file.

Scenario 3: an invitation or QR link is lost or expires#

An invitation is a bootstrap capability, not an identity. It is time-bounded and single-use, so a lost or expired invitation has a simple remedy: an authorized member creates a new one. Nothing about the policy or existing devices is affected by a lapsed invitation.

Device and Member Enrollment

Scenario 4: app reinstall or local storage loss#

The ClearDNS app keeps its sensitive material (identity and resolver configuration artifacts) in platform secure storage. A reinstall can lose that local state without losing the policy, because two recovery anchors exist outside the app's own storage:

• a one-way platform-derived recovery identifier lets a reinstalled app on the same physical device locate its previous enrollment; it is used only as one part of the platform recovery flow and does not replace the binding and subscription authority checks that flow requires;
• for app-store subscriptions, the store's own entitlement (restore purchases) proves the subscription relationship.

Recovery of resolver-bearing artifacts is strict: credential-bearing configuration is only re-issued for the exact policy/member/device binding it belongs to. A recovery flow never hands one device's artifacts to a different device, and knowing a Policy ID is not recovery authority.

Scenario 5: the subscription exists but local identity is lost#

Recovery behavior depends on the subscription channel.

App-store subscriptions#

For subscriptions purchased through the platform app stores, the store subscription itself is the durable recovery anchor. The platform can verify an active store entitlement. When an active store entitlement is successfully verified, the activation flow can recover service into a working policy: if the subscription's policy still exists, it is reactivated and the device re-enrolls into it; if that policy is gone, a fresh policy is provisioned under the same entitlement.

No email or account is needed for this, because the proof is the store entitlement, which the platform authenticates.

Web subscriptions#

Web subscriptions have no app-store anchor. Their continuity anchors are the enrolled devices themselves: any still-authorized device can reach the dashboard, manage the policy and enroll replacements.

Your payment method is not your ClearDNS identity.

For web subscriptions, billing information is not policy identity. If every authorized possession factor for the existing policy is lost, ClearDNS does not reconstruct the old policy from payment records alone: any recovery channel that accepted payment details as proof of policy ownership would also accept them from someone who merely obtained those payment details.

The user may cancel the existing subscription and create a fresh ClearDNS profile. Billing assistance and policy access remain separate, and an unused policy runs out through the normal lifecycle rather than lingering. ClearDNS also does not use payment-email delivery as a hidden copy of the resolver identity.

Security PIN recovery#

ClearDNS does not use email-based password recovery because there is no ClearDNS account password to reset. Security PIN recovery uses one-time PIN Recovery Codes generated for the member's PIN credential.

ClearDNS stores verifiers for the PIN and PIN Recovery Codes rather than storing their plaintext values. PIN Recovery Codes are shown when a set is generated and are not later recoverable from the server in plaintext.

A valid unused PIN Recovery Code can authorize a PIN reset. Resetting the PIN consumes the recovery proof, replaces the PIN and rotates the complete PIN Recovery Code set. Previously issued PIN Recovery Codes stop working.

Changing the PIN also rotates the complete PIN Recovery Code set and invalidates earlier factor-satisfaction state tied to the previous PIN version.

If the PIN and every valid PIN Recovery Code are lost, ClearDNS does not provide a hidden support-side master PIN or email-password fallback. Any other recovery method must use a separately supported and verified recovery factor.

Scenario 6: all devices lost#

Putting the pieces together:

• With an app-store subscription: recoverable when the store entitlement verifies. Reinstall the app on a device signed into the same store account, restore purchases, and the verified entitlement recovers the service as described above.
• Without a store anchor and without any authorized device or configuration: not recoverable by design. ClearDNS cannot distinguish the true owner from a stranger without either a possession proof (device, binding, configuration) or a platform-authenticated entitlement, and it refuses to invent a weaker proof, because any recovery channel that works without possession would also work for an attacker.

This is the accountless recovery contract: identity is possession plus platform-verifiable entitlement, and the product is built so that the durable anchors (bindings and store subscriptions) survive everything that is supposed to be temporary.

Lifecycle summary#

Related technical references#

• Identity and Resolver Credentials
• Device and Member Enrollment
• Accountless Dashboard Authentication
• Security Model