ProRDP Security

ProRDP is built by a former Microsoft security engineer (read the story behind it), and held to the highest security standards from the first line of code.

It starts with what ProRDP doesn’t do:

• No cloud account required. ProRDP is free for home and personal use with no sign-up, no account, and no license key. Download it, and the server runs on your Mac without any cloud dependencies.
• No cloud servers in the middle. Clients connect straight to your Mac. There’s no relay, broker, or ProRDP server that your sessions pass through, so there’s nothing in the cloud that could see, record, or intercept them.
• Your remote desktop data stays within your network. Your screen, keyboard and mouse input, clipboard, files, and audio travel only between the client and your Mac, encrypted with TLS.

A commercial license adds a ProRDP portal account and cloud features such as Entra ID sign-in, but your sessions still connect directly to your Mac and never pass through ProRDP’s servers.

The rest of this page covers how ProRDP gets from source code to your Mac, and what stops anyone from swapping in something else along the way. For the settings that protect connections, such as the TLS certificate, the audit trail, and session recording, see Settings › Security.

Signed and notarized

Every release of ProRDP is signed with ProRDP’s Apple Developer ID and notarized by Apple.

• Developer ID signature. The app and the disk image it comes in are both signed with a Developer ID certificate issued by Apple to ProRDP’s developer team. If a single byte of the app changes after it’s signed, macOS refuses to open it.
• Notarization. Before a release is published, Apple scans it for malicious content and issues a notarization ticket. The ticket is stapled to both the app and the disk image, so Gatekeeper can check it even when the Mac is offline.
• Hardened runtime. The app runs with macOS’s hardened runtime, which blocks code injection, loading unsigned libraries, and attaching a debugger to the process.
• No entitlements. The app asks for no extra entitlements: no JIT, no camera, no microphone, no Apple events, and no exceptions to the hardened runtime. Screen Recording and Accessibility are permissions you grant in System Settings, not entitlements the app grants itself.

macOS ties Screen Recording and Accessibility to the app’s signing identity. Because every version carries the same Developer ID and bundle identifier, your permissions carry over to each update, and a copy signed by anyone else wouldn’t inherit them.

Checking a copy yourself

You can confirm that a copy of ProRDP is genuine with Apple’s own tools. In Terminal:

spctl --assess --verbose /Applications/ProRDP.app

A genuine copy reports accepted and source=Notarized Developer ID. To see who signed it:

codesign --display --verbose=2 /Applications/ProRDP.app

Look for Identifier=com.prordp.prordp and TeamIdentifier=45J7H6U23W. Any other team identifier means the copy didn’t come from ProRDP.

Supply chain

Every system a release passes through is somewhere it could be tampered with, so ProRDP keeps that list as short as possible. Its code, its builds, and its releases all live on GitHub, and Apple is the only other party involved.

This website and ProRDP’s licensing service run in Azure, and neither has any part in building or delivering a release. Compromising them couldn’t put a binary on your Mac.

Builds

Release builds run on GitHub Actions, and only official releases can use ProRDP’s signing credentials. Everyday builds, such as pull requests and branch pushes, never see them. The build pipeline is deliberately kept small, using only a minimal set of SHA-pinned Actions workflows. A finished build stays private until the release manager has reviewed and signed it, and only then reaches the public release repository.

Immutable releases

The public release repository uses GitHub’s immutable releases. Once a release is published, GitHub refuses any change to its files or its tag, from anyone, including someone holding a leaked publishing token. A release can be deleted, but never swapped for a different file, and its tag can never be reused. A broken release is fixed with a new version number.

Update security

ProRDP checks for updates once a day, and installs one only when you click Install and Relaunch. Before it installs anything, the update has to pass two independent signatures, held in two different places:

1. The update signature, from the release manager. After CI finishes a build, the release manager downloads it and checks it the same way an installed copy will: its Developer ID signature, its notarization, its team, its bundle identifier, and its version. Only then do they sign a small manifest naming the disk image’s size and SHA-256 hash. That signing key stays off the cloud, and has never been stored in GitHub or given to CI. Every copy of ProRDP has the matching public key built in.
2. The Developer ID signature and notarization, from Apple. The app inside the update must be signed by the same Apple developer team as the copy you have installed, and notarized by Apple.

This means a compromised build pipeline can produce a disk image, but no copy of ProRDP will accept it, because CI never holds the update key. And someone who stole the update key still couldn’t ship a build that wasn’t signed with ProRDP’s Developer ID and notarized by Apple.

The release is checked again on the way out, and every day after:

• Before publishing. The publishing workflow re-checks the manifest’s signature against the disk image with a separate implementation, and publishes nothing if they don’t match.
• Every day. A scheduled job re-verifies every published release, and alerts the maintainer if any release is unsigned or no longer matches its signature.

On your Mac, ProRDP verifies the signature before it reads the manifest, checks the disk image’s hash before it mounts it, refuses to roll back to an older version, and checks the exact copy of the app it’s about to install. For every check and what it protects against, see Updates › How updates are signed.

Dependencies

ProRDP is written entirely in Swift, and has no third-party dependencies. There are no Swift packages, CocoaPods, frameworks, or libraries from anyone other than Apple.

• The RDP server is custom for ProRDP. Everything that parses what a client sends, including connection setup, sign-in, graphics, input, clipboard, and audio, is Swift code written for ProRDP. It doesn’t embed any existing RDP projects or any other RDP library. TLS itself is handled by macOS.
• Everything else is Apple’s. Screen capture, video encoding, networking, cryptography, the keychain, and the interface all use frameworks that ship with macOS, such as ScreenCaptureKit, VideoToolbox, Network, CryptoKit, Security, and SwiftUI. Apple updates them with macOS.
• Swift 6 strict concurrency. The whole app is built in Swift 6 language mode, where the compiler checks for data races.

Writing the protocol in Swift, rather than wrapping a C library, means the code that handles untrusted network input gets Swift’s memory safety: bounds-checked buffers and automatic memory management, which rule out most of the buffer overflows and use-after-free bugs behind remote desktop vulnerabilities. And with no third-party dependencies, there’s no package registry, transitive dependency, or abandoned library for an attacker to compromise on the way into ProRDP.

Limits

No system is impossible to break, so here’s what the measures above don’t cover.

• Both keys stolen. Someone holding both the update key and ProRDP’s Developer ID certificate could ship an update. They’re kept in different places so that stealing one doesn’t give you the other.
• Your first download. The update signature protects updates. Your first copy is protected by Apple’s Developer ID and notarization checks, which you can check yourself.
• Hidden releases. Someone controlling the release repository could stop you hearing about a new version, but couldn’t change what you install. The daily check would notice a release going missing.
• Reproducible builds. ProRDP’s source is private, and its builds aren’t reproducible, so you can’t independently confirm that a release matches its source.