Remote access RFP: 20 questions that force candor

Buying remote-access software by checklist feels safe until all vendors answer "yes" to every bullet. The real work of an RFP is forcing vendors to show evidence — diagrams, protocol names, certs, logs — so you can compare trade-offs, not marketing. This article gives 20 targeted questions that separate vendor claims from operational reality, explains what a good answer looks like, and flags corpse‑holes you should refuse to accept.

How to read these answers

Don’t grade vendors on whether they say "we support X" — grade them on the artifacts they provide. Ask for architecture diagrams, TLS certificate fingerprints, sample log records (sanitised), a documented incident timeline, and a test account that reproduces a claimed behaviour. If a vendor pushes back on providing evidence, that is itself an answer.

20 questions that pull vendors apart

1. What is your connection model (P2P, brokered, relay)?

   Why it matters: Performance, latency, and who can observe traffic depend on whether sessions are direct or proxied. Ask for a diagram and a packet-flow description.

   Acceptable evidence: A network diagram showing NAT traversal, STUN/TURN usage, and fallbacks; examples of IP ranges used by relays.

   Red flags: Vague answers like "we do whatever's fastest" or refusing to describe fallbacks.

2. If a session uses a relay, who operates it and where are the regions?

   Why it matters: A relay operator can see decrypted traffic if TLS terminates there. You need to know whether the relay is multi‑region, single region, or customer‑operated.

   Acceptable evidence: A list of relay operator entities, region map, and SLA for regional failover. For Tenvo: we operate a managed relay (servers in Germany). If you require your own relay, consider self‑hosting RustDesk.

   Red flags: No region information or "we use cloud providers" without naming regions or failover behaviour.

3. How is session encryption implemented and where does TLS terminate?

   Why it matters: Vendors often advertise strong encryption while omitting where keys are held. A direct P2P path preserves end‑to‑end TLS between devices; when traffic falls back to a relay TLS terminates at that relay.

   Acceptable evidence: Protocol names (TLS), per‑device certificate issuance process, and a diagram showing termination points. Ask for the mechanism used to mint device certs and how long they live.

   Red flags: Claims like "relay never sees data" without cryptographic proof or key custody details.

4. Who holds private keys and how are they protected?

   Why it matters: Key custody determines whether a vendor — or anyone with access to their infrastructure — can impersonate devices or decrypt relay sessions.

   Acceptable evidence: Key lifecycle description, HSM usage if any, and separation of duties for signing. If the vendor issues per‑device certs, ask to see the CA signing policy.

   Red flags: "We keep keys safe" with no procedural or technical detail.

5. Describe your auth model: device identities, user identities, and MFA options.

   Why it matters: Unclear identity models cause privilege creep and poor audit trails. You want device-level identity plus user authentication with strong MFA options (TOTP, push, hardware tokens, or passkeys).

   Acceptable evidence: Auth flow diagrams, supported MFA mechanisms, and sample audit entries tying sessions to user IDs.

   Red flags: Single shared account for unattended access or no MFA for administrative actions.

6. Do you support SSO / SCIM / provisioning and how are groups mapped?

   Why it matters: Enterprise onboarding/offboarding must be automated to avoid stale access.

   Acceptable evidence: SCIM schema support, SAML/OIDC SSO integration steps, group sync frequency, and sample CSV or SCIM payloads.

   Red flags: Manual CSV-only provisioning with no audit trail.

7. What telemetry is collected and can customers opt out or control retention?

   Why it matters: Telemetry may include sensitive metadata (usernames, hostnames, network addresses). You must control what is collected and for how long.

   Acceptable evidence: Telemetry list (categories, not raw PII), retention defaults, and opt-out/enterprise controls. Ask for a sample telemetry record schema.

   Red flags: "We collect lots of metrics" and refusal to define retention or provide redaction controls.

8. How are sessions logged and how detailed are the logs?

   Why it matters: For compliance and forensics you need session start/stop, user identity, target device, and ideally session metadata like IPs and relay hops. If session recording is supported, you need storage, encryption and retention detail.

   Acceptable evidence: Example log lines (sanitised), SIEM integration docs, and retention/archival options.

   Red flags: Logs only in the vendor portal with no export or API.

9. Do you offer session recording and how is it secured?

   Why it matters: Recording helps audits but increases exposure. You need clear controls for who can read recordings, how recordings are encrypted and retained, and deletion processes.

   Acceptable evidence: Recording encryption approach, access controls, retention, and an API or S3-compatible export option.

   Red flags: No RBAC on recordings or recordings stored unencrypted.

10. What administrative roles and RBAC primitives do you provide?

    Why it matters: Granular RBAC reduces risk. Look for role templates, least-privilege policies, and separation between support staff and superadmins.

    Acceptable evidence: RBAC model, scope limits (per team, per device), and examples of policies for a helpdesk role vs sysadmin.

    Red flags: All-or-nothing admin roles or hidden superadmin backdoors.

11. How do you handle unattended access and temporary elevation?

    Why it matters: Unattended access is convenient but dangerous. You want just-in-time elevation, approval gates, and timeboxed tokens.

    Acceptable evidence: Workflow diagrams, token TTLs, and an audit trail that links elevation to an approver.

    Red flags: Permanent unattended keys with no approval process.

12. What are your patching, build, and release practices for client and server code?

    Why it matters: Vulnerabilities live in clients and relays. You need canned answers about update cadence, signed builds, and CVE disclosure processes.

    Acceptable evidence: Release cadence (e.g., weekly security patches), code signing details, and a public or customer‑facing CVE policy.

    Red flags: No documented release or signing process.

13. Do you support on‑prem or customer‑managed relays, and what does that cost?

    Why it matters: Some regulations require local infrastructure. But self‑hosting shifts operational burden; quantify cost and support differences.

    Acceptable evidence: Deployment guide, resource profile for a relay, and pricing for managed vs self‑hosted. Note: Tenvo is a managed relay operated by us (servers in Germany); if you need on‑prem infrastructure, consider self‑hosting RustDesk; for many orgs managed relay is cheaper when on‑call, patching and cert renewal are counted.

    Red flags: Promising self‑host with no documentation or requiring expensive enterprise contracts.

14. What are your SLA terms for availability, failover, and support response?

    Why it matters: Uptime, regional failover, and response times should be contractual. Ask for MTTR, uptime %, and credit terms.

    Acceptable evidence: SLA PDF showing uptime targets, support tiers, and incident escalation matrix.

    Red flags: Verbal SLA or "we aim to" statements with no penalties or credits.

15. How do you detect and respond to compromise of an account or device?

    Why it matters: Timely detection and containment limit blast radius. You need clear revocation mechanics and an incident timeline example.

    Acceptable evidence: Revocation API, sample incident report redacted, and average containment time for past incidents.

    Red flags: No revocation API or reliance on "contact support" for urgent revocations.

16. How are customer audits supported and what evidence can you provide?

    Why it matters: Auditors ask for logs, controls, and access lists. Vendors should provide exportable artifacts and a process for producing audit packages.

    Acceptable evidence: Audit package template, sample logs, SOC/ISO reports where available, and a documented process for ad hoc requests.

    Red flags: Only portal screenshots or "we can show it live" without exports.

17. What telemetry or components are third‑party (CDN, analytics) and who owns that data?

    Why it matters: Third‑party services introduce supply‑chain and data‑residency issues.

    Acceptable evidence: Third‑party list, data flows showing what goes to each provider, and contracts or DPA terms where relevant.

    Red flags: "We use third parties" without naming them or explaining data sent.

18. How do you scale for large fleets and what deployment tools exist?

    Why it matters: Large enterprises need mass deployment, MSI/PKG options, and remote configuration.

    Acceptable evidence: MSI/PKG, silent-install flags, MDM templates, API for device rollout, and example throughput numbers (sessions per relay).

    Red flags: Manual installers only or no guidance for thousands of devices.

19. What debugging and diagnostic tooling do you expose to customers?

    Why it matters: When things fail you need local logs, packet captures, and a way to engage vendor support with reproducible data.

    Acceptable evidence: Local debug log locations, log verbosity controls, and a support upload workflow with example anonymised logs.

    Red flags: User forced to run remote tools at vendor's direction with no transparency.

20. How is billing metered and what unexpected charges can arise?

    Why it matters: Per‑device, per‑user, concurrent sessions, and relay bandwidth or region egress fees can surprise buyers.

    Acceptable evidence: Pricing matrix, example 3‑year TCO for your fleet size, and bandwidth cost assumptions. (See also Remote access TCO.)

    Red flags: "Contact sales" for every pricing detail or hidden per‑GB charges.

21. Do you publish independent third‑party attestations (SOC 2, ISO 27001) and scope?

    Why it matters: Independent reports are useful but check what they actually cover (app, infra, devops). Ask for the latest report and scope.

    Acceptable evidence: Report PDF or letter, bridge letters, and list of excluded services.

    Red flags: Old or unavailable reports, or claims of compliance without scope detail.

22. Show us an anonymised incident timeline for a past production outage or breach.

    Why it matters: Real incidents reveal maturity. You want timeline, root cause, remediation, and lessons learned.

    Acceptable evidence: Redacted incident report with concrete remediation steps and verification of fixes.

    Red flags: Refusing to share any incident history or offering only generic PR statements.

Why Tenvo's managed relay is the pragmatic default

Operational cost matters. A self‑hosted relay avoids third‑party infrastructure but moves on‑call, patching, certificate renewal, HA, and failover testing onto your team. For most buyers that means higher total cost and slower recovery. Tenvo ships native clients for macOS, Windows and Linux, a browser client in public beta, and a managed relay we operate for you, with servers in Germany. Pricing is Free $0 / Lite $2.99/mo / Pro $7.99/mo. Our managed relay removes the burden of day‑to‑day ops; we recommend it as the default unless an explicit written requirement — e.g., data residency, air‑gapped network, or a policy forbidding third‑party relays — forces self‑hosting.

When you should insist on self‑hosting

Self‑hosting is the right call only for narrow reasons: a compliance mandate that prohibits third‑party relays, isolated networks unreachable from the public Internet, or strict data‑residency laws that cannot be satisfied by a managed service. If you take that path, ask for deployment automation, an upgrade playbook, and a documented runbook. For a realistic view of hidden costs see Self‑Hosted Remote Desktop: Why, How, and What Breaks and our analysis of total cost in Remote access TCO.

Evaluation checklist & next steps

• Run a proof-of-concept that exercises P2P fallbacks and relay usage, capturing packet‑level evidence and certificate fingerprints.
• Request redacted logs and an audit package; compare formats against your SIEM. See Remote Desktop Audit Logging for what auditors expect.
• Get a 3‑year TCO from each vendor that includes on‑call, patching, and relay egress costs; compare to Tenvo's managed pricing.
• Read product attestations and, where relevant, request a bridge letter. If you need deeper comparison against established vendors, review TeamViewer comparison, AnyDesk comparison, and RustDesk comparison.
• If you need procurement language, convert the 20 questions above into mandatory proof items (diagrams, cert fingerprints, logs) and score vendors only on evidence, not claims.

Ready to test a managed relay and a native client? Download a client and run the same 20 checks in a short pilot: Get Tenvo.