Device and Member Enrollment

ClearDNS needs to solve a problem that account systems normally hide behind "send an invitation to this email address." A ClearDNS policy may contain multiple devices and multiple member scopes, but those relationships are created without requiring every participant to register an account.

ClearDNS therefore treats enrollment as a controlled transfer of permission to create a new binding.

Two different enrollment intents#

Add another device#

A new device is attached to an existing member scope.

Add another member#

A new member scope is created under the policy, with its own device relationship and the permissions allowed by the invitation.

Those are different operations even when the user experience is presented through a QR code or link.

Invitation as a possession capability#

An invitation is a temporary possession capability. Invitations are generated by the server, are not predictable, and are never client-chosen.

A production invitation is:

• difficult to guess;
• time-bounded;
• constrained to its enrollment intent;
• permission-checked when created;
• single-use once accepted; and
• revocable through the policy's normal device/member controls after enrollment.

The raw invitation value is sensitive while it is valid.

Why invitations expire#

A shareable link can be copied through messaging, QR scanning, clipboard history or screenshots. A permanent invitation would unnecessarily extend that exposure. ClearDNS therefore gives invitations a finite acceptance window; after it closes, a new invitation is required. Expired pending invitations are also cleaned up so they cannot linger as latent capabilities.

Single-use acceptance#

Successful acceptance changes the invitation from a pending capability into a concrete policy/member/device relationship. The same invitation is not intended to keep minting unrelated device identities after successful use. An enrollment link is a bootstrap mechanism, not a permanent master credential.

Exact binding before resolver artifacts#

ClearDNS separates two events:

1. deciding which policy/member/device tuple is being enrolled; and
2. issuing the platform-specific resolver configuration for that tuple.

The enrollment flow verifies that the exact intended binding exists in authoritative state before issuing the corresponding resolver/profile artifact. A configuration response is never itself the authority; the validated relationship is.

Retry-safe enrollment#

Enrollment often occurs on mobile networks, embedded browsers and OS configuration flows where a request can be repeated or interrupted. The public contract is the outcome: an interrupted or repeated enrollment converges on the one relationship the successful enrollment claimed, and retries do not turn one legitimate invitation into uncontrolled duplicate identities.

Platform recognition and artifact issuance#

Different platforms need different configuration artifacts. ClearDNS keeps the identity relationship separate from the platform representation: the server validates the intended relationship and the relevant platform before issuing the configuration appropriate to that platform, so a configuration-bearing response is never treated as authority when the underlying relationship is missing or inconsistent.

Browser enrollment#

A browser can itself be represented as a separately controlled binding where the product requires it. Browser enrollment has additional lifetime and acceptance semantics because a browser may initially be attached through an invitation before it becomes a durable accepted relationship. ClearDNS handles that as binding state rather than creating a conventional browser account.

Device removal#

Removing or disabling a device is an authority change. A device configuration that still contains an old resolver credential does not by itself force the backend to keep the binding active forever. Resolver processing consults current authoritative binding/policy state and stops granting normal service to a binding that has been disabled or invalidated.

Recovery is not the same as enrollment#

Enrollment capabilities, resolver configuration, recovery authority and browser sessions are separate sensitive things and are not interchangeable. A recovery flow must prove the specific authority required to recover an artifact rather than accepting "I know the Policy ID." Sensitive resolver configuration is kept in platform secure storage when the app needs to retain it.

First-run Security PIN#

Security PIN establishment is part of first-run activation and provides the baseline credential for ongoing Dashboard administration.

If the member does not yet have a Security PIN, first-run activation establishes one and generates a PIN Recovery Code set. If the member already has a Security PIN, the new binding uses the member's current Dashboard security requirement, PIN by default or MFA when enabled.

The Security PIN belongs to the member within the policy, while the first-run security step is completed independently by each device binding. This gives one member one Security PIN and one PIN Recovery Code set across that member's devices without allowing a new device to skip the mandatory first-run step.

The Circle / policy is the managed network#

The unit ClearDNS manages is the policy, presented in the product as a Circle. A Circle is not a flat list of devices; it is a small managed network:

policy / Circle
    ->
member scopes
    ->
individual devices

• Roles. Every binding carries a role: owner, admin or member. Owner and admin can administer the policy and its members; a member scope is limited to its own devices and the authority its role grants.
• Members and devices. A Circle holds one or more member scopes, and each member scope can hold more than one device, up to a current per-member device limit. Paid seats set how many member scopes a policy can hold.
• Enrollment. Members and devices are added through the server-generated, time-bounded QR or share-link invitations described above, with a distinct intent for adding a device versus adding a member.
• Disable and removal. Any device or member binding can be disabled or removed, and resolver processing stops granting normal service to a disabled binding.
• Presence and Network History. For each device the product can show current presence, a last-seen time, and a per-device Network History of network identity and coarse geographic context. Network History carries no DNS query names.
• Analytics. Where the product state enables it, owner and admin can read per-member and per-device analytics through the User Insights and Device Insights views, and the policy-wide Live Traffic Map, as documented in Analytics and Live Observability.

Family safety without an account directory#

The result is a family and team model that does not require an email-address directory as its identity layer. Family capability is not a handful of category switches; it combines:

• category policy and SafeSearch;
• custom allow and block rules;
• member and device enrollment;
• role-aware administration;
• device presence;
• Network History;
• per-member and per-device analytics where enabled;
• policy-wide live visibility where enabled.

The Circle can know which member scopes exist, which devices belong to each member, which roles are authorized, and which devices are active, without a conventional account directory.

Security summary#

Related technical references#

• Identity and Resolver Credentials
• Accountless Dashboard Authentication
• Analytics and Live Observability
• Security Model