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 device proves its current ClearDNS relationship and a fresh session is established. 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: after it, the resolver stops granting normal service to that device, 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 authority as current server-side 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 supported platform recovery mechanism lets a reinstalled app on the same physical device locate its previous enrollment; it is only one part of the recovery flow and does not replace the 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 owner of an eligible policy who holds the Policy Recovery Code can instead recover the same existing policy through Policy Recovery, using the Policy ID and the current PIN or MFA factor, without any payment proof (see Policy Recovery below). Failing that, 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.

PIN Recovery Codes are shown when a set is generated and are not later recoverable from the server.

A valid unused PIN Recovery Code can authorize a PIN reset. Resetting or changing the PIN replaces the recovery code set, and previously issued PIN Recovery Codes stop working.

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.

Policy Recovery#

A policy owner who has lost every enrolled device is not at a dead end. Policy Recovery lets the owner of an eligible policy recover the same existing ClearDNS policy using the Policy ID, the owner-held Policy Recovery Code, and their current PIN or MFA factor. Recovery is reached at https://cleardns.com/recover, and on success the owner enrolls a new device through the normal setup flow.

The contract is deliberately narrow:

• it requires no email, username or password;
• it does not use payment information as identity proof;
• it does not restart a trial, extend or restore a subscription, or grant features beyond the policy's current entitlement; normal entitlement rules still apply;
• it cannot downgrade MFA to PIN: an MFA-mode owner must satisfy MFA;
• it cannot resurrect a destroyed policy, which is terminal;
• it provisions access back to the same eligible existing policy and never mints a replacement policy.

Policy Recovery is available for eligible existing policies in TRIAL, ACTIVE, GRACE or EXPIRED status. The owner must provide the Policy ID, the Policy Recovery Code and the applicable current Security PIN or MFA factor. Recovery enrolls a new device into the same eligible policy. It does not restart a trial, extend a subscription or grant features beyond the policy's current entitlement. Provisional and destroyed policies are not eligible for public Policy Recovery.

Three distinct recovery objects, never interchangeable:

• the Policy Recovery Code recovers the policy, together with the Policy ID and the current factor;
• PIN Recovery Codes reset the Security PIN;
• MFA Backup Codes are for emergency MFA authentication.

Each is a separate credential for a separate purpose. Policy Recovery is a stronger accountless model precisely because it restores an existing policy from an owner-held code plus the current security factor, rather than reconstructing identity from an email address or payment record.

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.
• The owner of an eligible policy, using Policy Recovery: recoverable with the Policy ID, the owner-held Policy Recovery Code, and the current PIN or MFA factor, as described above. This restores access to the same existing policy.
• Without a store entitlement, without any authorized device, and without the owner's Policy Recovery Code and current factor: not recoverable by design. Provisional and destroyed policies are never eligible for Policy Recovery, and a destroyed policy is terminal. ClearDNS refuses to invent a weaker proof, because any recovery channel that works without the owner's code and current factor would also work for an attacker.

This is the accountless recovery contract: recovery rests on possession, or an owner-held Policy Recovery Code plus the current security factor, or a platform-verifiable store entitlement, and the product is built so that the durable anchors survive everything that is supposed to be temporary. Payment records are never the recovery key.

What removal and expiry mean for retained data#

Removing a device or ending a policy is first an authority change: the resolver and dashboard stop honoring the removed relationship. What happens to already-retained data is a separate question.

Removing a device or member ends its authority going forward. Changing to a product state without historical analytics stops new historical query collection. Ending a policy ends future policy-linked service activity. Records already created follow the retention or operational lifecycle disclosed for their category on the privacy page; historical DNS query data is never retained beyond 90 days, and if historical analytics is enabled again later, an earlier ended history period is not restored as part of the new history period.

ClearDNS states this rather than implying that removal is retroactive erasure, because the two are different promises. Removal is immediate loss of authority; retained data ends by its category's documented lifecycle.

Lifecycle summary#

Related technical references#

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