- Operators keep route, DNS, fallback, credential, and rollback ownership by default.
- Support can recommend changes, but live apply windows require explicit operator approval.
- Recovery access should be confirmed before anyone touches a working gateway.
Support boundaries
Paid support helps operations without owning traffic.
Operators keep credentials, traffic paths, and final approvals. Support stays scoped to explicit approval, redacted evidence, and named ownership for route, DNS, fallback, and recovery decisions.
- Guided install, upgrade help, and recovery review.
- Privacy posture review based on operator-provided evidence.
- Policy design guidance for routes, DNS, fallback, bridge paths, and device groups.
- MSP onboarding guidance, templates, and handoff review.
- A guarantee of anonymity.
- Endpoint cleanup, browser fingerprinting fixes, legal advice, or payment-trail cleanup.
- Silent live changes to routing, DNS, firewall, credentials, or remote access.
- Traffic inspection as a default support requirement.
- Remote access must be explicit, time-limited, revocable, and logged.
- Support bundles should be generated by the operator, redacted before export, and scoped to diagnostics.
- Reports should separate assumptions, observed behavior, remaining risks, and next actions.
Change window rules
Name who owns the risky parts before support begins.
- Name the current route owner, DNS owner, fallback owner, and final policy approver.
- Separate advisory review from a bounded live change window.
- If a live change window is delegated, record the exact routes, DNS settings, fallback rules, credentials, and remote-access scope that support may touch.
- Record who can approve rollback if the intended privacy posture is not met.
- Set a clear end condition for delegated access: rollback complete, validation passed, or the operator closes the window.
- Confirm console, SSH, or local recovery access before route, DNS, firewall, or remote access changes.
- Keep a known-good rollback target for policy, resolver, and transport state.
- Stop the change window if recovery access or rollback evidence is missing.
- Share only the route, DNS, fallback, privacy posture, and failure evidence needed for the request.
- Keep support bundles redacted and generated by the operator.
- Return full ownership to the operator at the end of the window and summarize what changed, what did not, and what still needs operator approval.
- State remaining uncertainty when support cannot verify behavior directly.
Ownership matrix
Keep route, DNS, fallback, rollback, and support authority explicit through close-out.
Approves route intent, path changes, and the final apply window for traffic changes.
Support can review route evidence and suggest safer policy, but should not become the standing route owner for a live site.
Approves resolver policy, upstream DNS changes, split-DNS behavior, and DNS rollback.
Guided changes should stop if the current DNS source of truth, rollback authority, or intended resolver behavior becomes unclear.
Approves when fallback is disabled, degraded, or allowed and what event triggers each mode.
Privacy posture claims depend on this choice, so fallback state and trigger conditions should stay visible before validation begins.
Approves back-out conditions, the known-good target, and the point where support stops changing state.
Recovery access, rollback proof, and the stop trigger should be named before a live support window opens.
Stays inside the scoped request, records what was touched, and hands control back at close-out.
Close-out should confirm what changed, what remained under operator ownership, whether delegated access was revoked, and which approvals are still pending.
Before remote help
Set the intake, evidence, and stop conditions before any access window opens.
- Share only the deployment facts, route or DNS goals, fallback expectations, and recovery details needed for the request.
- Do not send keys, tokens, passwords, full packet captures, or unredacted topology by default.
- Make retention, revocation, and remote-access expectations explicit before evidence leaves the operator.
- Bring route traces, DNS behavior, fallback policy, leak checks, and the last known-good rollback point.
- Keep support bundles operator-generated, redacted, and scoped to the exact diagnostic question.
- Separate observed behavior, assumptions, remaining risk, and operator approvals in the handoff note.
- Stop immediately if route ownership, DNS ownership, fallback authority, or rollback approval becomes unclear.
- Stop if recovery access fails, diagnostics expand beyond the agreed scope, or the operator withdraws approval.
- Close the window with a written summary of what changed, what stayed under operator control, and what still needs approval.
Cross-check contact and intake privacy, support bundle redaction, and rollback and recovery, then launch status before a live support window starts.