Perimeter 81 vs Azure AD App Proxy for remote desktop access

Having recently finalized a design for a client migrating legacy on-premises applications to a hybrid cloud model, the choice between a dedicated SASE/ZTA platform like Perimeter 81 and leveraging a native cloud tool like Azure AD Application Proxy for remote access became a central architectural debate. Both aim to solve the "secure access to internal resources" problem, but their philosophies, operational overhead, and ultimate fit diverge significantly, especially for a use case as specific as remote desktop (RDP).

The core distinction is that Azure AD App Proxy is primarily an **authentication and conditional access broker** for web and RDP/SSH *applications*. It's a layer 7 reverse proxy integrated directly into your Entra ID (Azure AD) tenant. Perimeter 81, conversely, establishes a **full network-layer Software-Defined Perimeter (SDP)**. It creates an encrypted, identity-aware network overlay where the user's device behaves as if it's on the same private network as the resource, regardless of physical location.

For RDP access specifically, this leads to critical practical differences:

* **Connectivity Model:**
* **Azure AD App Proxy:** Requires the RDP client to support web-socket connections via the HTML5 web client or the Microsoft Remote Desktop client. The connection is brokered through Azure. Direct native RDP port (3389) connectivity from the public internet is not exposed, which is a security positive, but can introduce latency and requires the App Proxy connector(s) deployed in your network.
* **Perimeter 81:** Establishes a secure tunnel (via a local agent or client) to the nearest gateway. The user then uses their **standard native RDP client** (mstsc.exe) directly to the private IP of the target server. The experience is identical to being on the local LAN.

* **Architecture & Dependencies:**
```yaml
# Azure AD App Proxy Flow (Simplified)
User -> Entra ID Auth -> Conditional Access Policies -> App Proxy Service -> App Proxy Connector (On-Prem) -> Target RDP Server

# Perimeter 81 Flow (Simplified)
User -> P81 Client (Auth + ZTNA Check) -> Secure Tunnel -> P81 Gateway -> Target RDP Server (via Private IP)
```
The Azure model is heavily dependent on your Entra ID ecosystem and requires maintaining connector VMs. Perimeter 81 introduces a separate identity and policy plane, which can be an advantage (multi-cloud, non-Azure resources) or an added layer of management.

* **Cost & Complexity:**
* **Azure AD App Proxy** is included in certain Entra ID P tiers. Your costs are the Azure VMs for connectors and the Entra ID licenses. Operational complexity lies in managing connector groups, high availability, and application registration/configurations in Azure.
* **Perimeter 81** is a dedicated service with per-user/month pricing. It abstracts away the gateway infrastructure management, but you are now administering a separate policy console. The value is in its breadth of features (network segmentation, DNS filtering, firewall-as-a-service) beyond just app proxying.

**Recommendation:** If your environment is deeply entrenched in the Microsoft ecosystem, your remote access needs are limited to a defined set of published applications (including RDP), and your team is proficient in Entra ID Conditional Access, App Proxy can be a cost-effective solution. However, if you require a true network-level, any-protocol access (not just HTTP/RDP/SSH), have resources across multiple clouds/DCs, or need unified policies covering network and application access, a SASE platform like Perimeter 81 is the more robust and scalable choice, despite the higher direct cost. For my client with a mix of Azure VMs, AWS EC2 instances, and a physical data center, the unified access model of Perimeter 81 justified the investment.

- Mike