Remio security architecture, plainly stated.

§01 · Executive summary

Remio is a remote desktop application built on a zero-knowledge, peer-to-peer architecture. Screen content, input data, and audio streams are end-to-end encrypted between devices using industry-standard DTLS-SRTP with AES-256. Unlike centralized solutions, Remio's signaling server only facilitates initial connection establishment — it never sees, processes, or stores 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: 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.

§02 · Threat model

Remio's security architecture is designed against a set of threat scenarios relevant to remote desktop usage in both enterprise and personal contexts. We are explicit about what we protect against, and where the trust boundaries lie.

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.
• Server compromise. Even if our signaling server is fully compromised, attackers gain access only to 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; 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.

§03 · Architecture overview

Remio separates the signaling plane (connection setup) from the data plane (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. Once the P2P connection is established, the signaling server is no longer involved.

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

§04 · 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.

• 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

# Supported TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# DTLS cipher suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Key rotation

Keys are rotated automatically at the following boundaries:

• Session start. A 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.

§05 · Authentication and 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 signed tokens (24-hour expiry) 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.

AI agent access (Remio MCP Server)

Remio is extending this same trust model to AI agents. Tools like Claude Code, Codex, or the Claude app can operate your machines remotely through the Remio MCP Server — and the security boundary is identical to the one a human client crosses:

• Everything is gated by your sign-in. An agent can only reach hosts that are online and paired to the account you authenticated with (Google or Apple sign-in, via OAuth). No authenticated account, no tools.
• Remio is a broker, not an operator. The MCP server's only job is to expose a set of tools scoped to your authenticated account and hand them to the AI tool you chose to connect. Remio cannot start a session with your machine on its own — a host only accepts connections that present proof of your account's authorization, exactly like the device trust model above.
• Same encrypted transport. Agent sessions ride the same end-to-end encrypted channels described in §04. Our servers still see only encrypted blobs — the zero-knowledge properties in §06 apply unchanged.
• Visible, killable, audited. An agent session is shown on the host while it runs, can be terminated instantly with a kill switch, and is recorded in a local audit log.

§06 · 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 — the same SRTP encryption as video.
• Input events — mouse, keyboard, touch are DTLS-encrypted.
• Cursor position — transmitted via encrypted data channel.
• File content — any file transfer occurs over encrypted channels.
• Clipboard data — encrypted data channel.
• Application state — what apps you are running, what you are 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:

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

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.

§07 · 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 on the same network.
2. Server-reflexive candidates (STUN) — NAT traversal via STUN servers to discover the public IP.
3. Relay candidates (TURN) — encrypted relay when a direct connection cannot be established.

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

Configurable transport policies

Connections default to preferring direct P2P with automatic fallback to the encrypted relay. Stricter policies — forcing all traffic through the relay, or skipping LAN discovery entirely — are available for locked-down network environments.

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 a global edge network.
• Layer 3, 4, and 7 DDoS mitigation.
• Web Application Firewall (WAF).
• Rate limiting at the edge before traffic reaches origin.
• Bot detection and challenge pages.

§08 · 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 are 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 the background.

Code signing & verification

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · 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 acknowledge receipt within 48 hours.
4. We aim to resolve confirmed vulnerabilities within 30 days.
5. Reporters are credited in our security changelog, unless they prefer anonymity.

Responsible disclosure policy

• We request a 90-day disclosure window before public disclosure.
• We do not pursue legal action against researchers acting in good faith.
• We prioritize fixes by severity: critical, high, medium, low.
• A formal bug bounty program is on our 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 the auto-update infrastructure.
5. Post-mortem. Publish a transparency report.

§10 · 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 do not 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 for 2026.
• SOC 2 Type I — initial organizational controls assessment.
• SOC 2 Type II — ongoing compliance verification.
• Bug bounty program — formal responsible-disclosure rewards.

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 and DigitalOcean) processes only connection metadata — and this metadata is not linked to any personal information.

§11 · Comparison with alternatives

The remote desktop industry has been plagued by high-profile security breaches. Here is 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.

§12 · 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 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.

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

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