Remio Security Architecture:
A Technical Overview

Executive Summary

Remio is a remote desktop application built on a zero-knowledge, peer-to-peer architecture where screen content, input data, and audio streams are end-to-end encrypted between devices using industry-standard DTLS-SRTP protocols with AES-256 encryption. Unlike centralized solutions, Remio's signaling server only facilitates initial connection establishment — it never sees, processes, or stores any session data. There are no accounts required, no passwords to breach, no central database of credentials. Device pairing uses proximity-verified PINs, and all keys are ephemeral with Perfect Forward Secrecy, meaning that even if a key is compromised, past and future sessions remain cryptographically secure. This architecture eliminates entire categories of attacks that have plagued competitors — because there is simply nothing to steal.

Threat Model

Remio's security architecture is designed to protect against a comprehensive set of threat scenarios that are relevant to remote desktop usage in both enterprise and personal contexts.

Threats We Protect Against

• Eavesdropping — All media (video, audio) and data channels (input, keyboard, cursor) are encrypted with SRTP and DTLS respectively. A network observer sees only encrypted packets with no ability to reconstruct session content.
• Man-in-the-Middle (MITM) — DTLS handshake with certificate fingerprint verification prevents interception. The signaling channel uses TLS 1.3 with Perfect Forward Secrecy (PFS), making MITM attacks on the signaling path equally infeasible.
• Server Compromise — Even if our signaling server is fully compromised, attackers gain access to only connection metadata (IP addresses, timestamps). Session content is never transmitted through or stored on our servers.
• Unauthorized Access — PIN-based pairing requires physical proximity or knowledge of a displayed PIN. No remote-accessible credential database exists to attack.
• Credential Theft — No passwords, no accounts, no central credential store. Device trust is established through PIN pairing, and session tokens (JWT) are short-lived and device-bound.
• Session Replay — SRTP's built-in replay protection and DTLS sequence numbers prevent captured packets from being replayed.
• Supply Chain Attacks — All Remio binaries are code-signed. macOS builds are notarized by Apple. iOS builds are distributed exclusively through the App Store.

Trust Boundaries

Our threat model explicitly defines three trust boundaries:

1. Device boundary — Each device is trusted only after PIN verification. OS-level protections (sandboxing, Keychain, Secure Enclave) protect on-device data.
2. Network boundary — All data in transit is encrypted. We assume the network is hostile.
3. Server boundary — Our own servers are treated as untrusted relays. They facilitate connections but cannot inspect content.

Architecture Overview

Remio separates the signaling plane (connection setup) from the data plane (actual streaming). This separation is fundamental to our zero-knowledge design — the server that helps you connect never touches the data you exchange.

Signaling vs. Data Plane

The signaling server's sole responsibility is to relay SDP offers/answers and ICE candidates between devices during connection setup. These are the WebRTC handshake messages that allow two devices to discover each other and negotiate a direct connection. Once the P2P connection is established, the signaling server is no longer involved.

The server cannot parse the payload content — it is a binary blob that only the target device can interpret. The FlatBuffers binary protocol adds an additional layer of structure that makes injection attacks more difficult compared to JSON-based signaling.

Encryption Layers

Remio employs a multi-layered encryption strategy where each communication channel uses the cryptographic protocol best suited to its requirements.

Perfect Forward Secrecy

Every Remio session generates a unique set of ephemeral encryption keys through ECDHE key exchange. This means:

• Compromising the current session key does not expose past sessions
• Compromising the current session key does not expose future sessions
• Each key pair exists only for the duration of a single session
• Keys are never stored to disk — they exist only in memory

Cipher Suites

Key Rotation

Keys are rotated automatically at the following boundaries:

• Session start — New DTLS handshake generates fresh keys for every connection
• SRTP key derivation — Media keys are derived from the DTLS handshake and are unique per media track
• Reconnection — If a session is interrupted and reconnected, a completely new key exchange occurs

Authentication & Pairing

Remio deliberately avoids traditional username/password authentication. Instead, we use a PIN-based device pairing model that eliminates the most common attack vectors in remote desktop software.

PIN-Based Pairing

When a client wants to connect to a host for the first time, the process works as follows:

1. The Host displays a short numeric PIN on its screen (or as a QR code)
2. The Client enters the PIN, which is sent via the signaling channel to the Host
3. The Host validates the PIN and confirms or rejects the pairing
4. On success, a device trust relationship is established
5. Subsequent connections from the same device do not require re-pairing

Device Trust Model

Once paired, each device is identified by a unique device ID. The Host maintains a local list of trusted devices. This trust relationship is:

• Stored locally — on the Host device only, in the OS Keychain
• Never transmitted — the server has no knowledge of which devices are trusted
• Revocable — the Host can remove a trusted device at any time

Session Tokens (JWT)

After pairing, short-lived JWT tokens are used for signaling server authentication:

These tokens authenticate a device to the signaling server for room creation and message relay. They do not grant access to session content, which is protected by a separate DTLS handshake.

Zero-Knowledge Design

Zero-knowledge is not a marketing term at Remio — it is an architectural constraint. Our systems are designed so that session content is structurally inaccessible to Remio, its employees, or any third party.

What Our Servers Can See

• IP addresses of connecting devices (required for networking)
• Connection timestamps
• Device IDs (opaque identifiers, not tied to personal information)
• Signaling metadata: SDP offer/answer exchange, ICE candidates

What Our Servers Cannot See

• Screen content — video frames are SRTP-encrypted end-to-end
• Audio — same SRTP encryption as video
• Input events — mouse, keyboard, touch are DTLS-encrypted
• Cursor position — transmitted via encrypted DataChannel
• File content — any file transfer occurs over encrypted channels
• Clipboard data — encrypted DataChannel
• Application state — what apps you're running, what you're working on

Data Retention Policy

Because of our P2P architecture, there is effectively nothing to retain:

• Session content — Never stored. Real-time stream only.
• Signaling logs — Connection metadata retained for up to 30 days for debugging, then deleted. Contains no session content.
• User accounts — No accounts required. Optional Firebase Auth data is managed by Google's infrastructure and can be deleted by the user.
• Device information — Stored locally on each device. Never uploaded to our servers.

P2P-First Data Flow

In the majority of connections (where NAT traversal succeeds), data flows directly between devices without touching any server:

Even in the TURN relay fallback scenario, the relay server handles only encrypted packets. It acts as a dumb pipe — it cannot decrypt, inspect, or modify the data.

Network Security

P2P Connection Establishment

Remio uses the ICE (Interactive Connectivity Establishment) protocol to find the best possible connection path between devices:

1. Host candidates — Direct LAN connection (same network)
2. Server-reflexive candidates (STUN) — NAT traversal via STUN servers to discover public IP
3. Relay candidates (TURN) — Encrypted relay when direct connection fails

The ICE agent tests all candidate pairs simultaneously and selects the lowest-latency, most reliable path. Direct P2P is always preferred.

Configurable Transport Policies

Rate Limiting

The signaling server implements aggressive rate limiting to prevent abuse:

Expired rate limiters are automatically cleaned up on a 5-minute interval with a 10-minute TTL, preventing memory exhaustion from distributed attacks.

DDoS Protection

Our signaling infrastructure is protected by Cloudflare, providing:

• Anycast DNS with global edge network
• Layer 3/4/7 DDoS mitigation
• Web Application Firewall (WAF)
• Rate limiting at the edge before traffic reaches origin
• Bot detection and challenge pages

Client Security

Remio leverages the full security stack of each operating system to protect local data and ensure application integrity.

macOS

• Keychain Integration — All sensitive data (device trust tokens, JWT) is stored in the macOS Keychain, protected by the user's login credentials and hardware encryption
• App Sandbox — Remio runs in a sandboxed environment with minimal permissions. Screen capture and accessibility require explicit user approval
• Code Signing — All builds are signed with Apple Developer certificates
• Notarization — macOS builds are notarized by Apple, confirming they are free of known malware
• Hardened Runtime — Prevents code injection, library hijacking, and debugging in production builds

iOS

• App Transport Security (ATS) — All network connections must use HTTPS/TLS. No exceptions configured.
• Secure Enclave — Where available, cryptographic keys are generated and stored in the Secure Enclave hardware
• Keychain Services — Device credentials stored in the iOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly protection class
• App Store Review — All iOS builds pass Apple's security review process
• No Background Data — The app does not collect or transmit data when in background

Code Signing & Verification

Incident Response

Security Track Record

As of February 2026, Remio has no history of security breaches or incidents. Our zero-knowledge architecture significantly reduces the attack surface — there is no central database of credentials or session data to target.

Vulnerability Reporting

We encourage responsible disclosure from security researchers. If you discover a potential vulnerability:

1. Email security@remio.net with a detailed description
2. Include steps to reproduce, if applicable
3. We will acknowledge receipt within 48 hours
4. We aim to resolve confirmed vulnerabilities within 30 days
5. Reporters will be credited in our security changelog (unless they prefer anonymity)

Responsible Disclosure Policy

• We request a 90-day disclosure window before public disclosure
• We will not pursue legal action against researchers acting in good faith
• We prioritize fixes based on severity (Critical → High → Medium → Low)
• A formal bug bounty program is on our roadmap Roadmap

Incident Response Process

In the event of a confirmed security issue:

1. Containment — Isolate affected systems within 1 hour
2. Assessment — Determine scope and impact within 24 hours
3. Communication — Notify affected users within 72 hours (GDPR-compliant)
4. Remediation — Deploy patches via auto-update infrastructure
5. Post-mortem — Publish a transparency report

Compliance

GDPR Readiness

Remio's zero-knowledge architecture is inherently GDPR-friendly because we minimize data collection to the absolute technical minimum:

• Data minimization — We collect only what is necessary for connection establishment
• Right to erasure — Since we don't store user content, there is nothing to delete. Optional account data can be deleted on request.
• Data portability — Device trust data is stored locally and controlled by the user
• Consent — PIN pairing is an explicit consent mechanism for each device
• No cross-border data transfers of content — P2P connections keep data between devices; it never enters our infrastructure

SOC 2 Roadmap

Planned Compliance Milestones

• Independent security audit — Professional penetration testing and code review Planned 2026
• SOC 2 Type I — Initial organizational controls assessment Roadmap
• SOC 2 Type II — Ongoing compliance verification Roadmap
• Bug bounty program — Formal responsible disclosure rewards Roadmap

Data Residency

Because Remio is P2P-first, session data resides wherever your devices are. Your data never leaves the direct connection between your devices. The signaling server (hosted with Cloudflare/DigitalOcean) processes only connection metadata — and this metadata is not linked to any personal information.

Comparison with Alternatives

The remote desktop industry has been plagued by high-profile security breaches. Here's how Remio's architecture fundamentally differs from centralized alternatives.

Why Centralized Architectures Fail

The fundamental problem with centralized remote desktop services is that a single breach can compromise all users. When AnyDesk's production servers were breached in February 2024, attackers stole code signing certificates, potentially allowing them to distribute malware disguised as legitimate AnyDesk software. All user passwords had to be reset.

When APT29 (a Russian state-sponsored group) breached TeamViewer's corporate network in June 2024, it raised questions about the integrity of the product itself — because a centralized architecture means the vendor has the technical capability to access sessions.

Remio eliminates this class of attack entirely. A breach of our signaling server yields only connection metadata. There are no credentials to steal, no sessions to access, no certificates that can be used to sign malicious software targeting our users' devices.

Conclusion

Remio's security is not a set of features bolted onto a product — it is a consequence of architectural decisions made from day one. By choosing P2P over centralized, PIN pairing over passwords, zero-knowledge over data collection, and open protocols over proprietary black boxes, we have built a remote desktop solution where security is the default state, not an optional upgrade.

We believe that privacy is not optional and that trust should be earned through transparency, not demanded through terms of service. This whitepaper is part of that commitment to transparency.

For questions, enterprise security reviews, or to report a vulnerability:

• Security inquiries: security@remio.net
• Enterprise sales: enterprise@remio.net
• General: hello@remio.net