--- canonical: https://openvpn.net/access-server/features/zero-trust-app-broker/ --- # Zero Trust Application Broker Give users access to one application instead of your whole network, with every connection verified first. ## Zero Trust Application Broker for per-application access Access Server brokers access to individual applications by domain name, verifying identity and context before connecting a user to a single authorized app. The client never receives a route to your private network, so lateral movement isn't blocked by a firewall rule, it's structurally impossible. Requires Access Server 3.1.0 or newer. ## One login shouldn't unlock your whole network Standard remote access works at the network level. A user authenticates, lands on a subnet, and firewall rules downstream decide what they can reach. Giving someone the one internal tool they need often means handing over a route to everything sitting next to it, so a single set of stolen credentials reaches far beyond the app it was meant for. Access Server closes that gap with Zero Trust, verifying every user before brokering their connection to authorized applications by name, so they reach the tools they're cleared for and there's no path left to anything else around them. ## Enforce Zero Trust Network Access (ZTNA) with Access Server Rather than granting network access and then restricting it with Access Control, Access Server operates as a Zero Trust Application Broker, brokering traffic to specific authorized applications via stand-in IPs without exposing the network itself. ### Verify first, connect second Access Server checks identity through SAML, LDAP, or RADIUS with MFA before brokering anything, and can add device and location checks on top. ### Keep applications hidden from discovery Access Server hands back a stand-in address, so clients never learn of your private network subnets or have a route to them. ### Enforce least privilege per user and per group Scope applications globally, by group, or by user, so each user reaches only authorized applications. ### Prove enforcement instead of asserting it DNS proxy logs show every query forwarded, mapped, or denied in real time, and NAT tables show the translation behind each rule, so you can demonstrate least privilege instead of asserting it. ### Write policies that survive infrastructure change Rules evaluate against hostnames, so your access policies hold when IPs churn behind CDNs and load balancers, leaving no address changes to chase and no allowlists to correct. ## Frequently asked questions ### Is the Zero Trust Application Broker a separate product or add-on? No. It's how Access Server behaves when you define access by domain rather than by subnet. Access Server verifies the user, then connects them to a single authorized application by hostname, assigning an intermediate address scoped to that app. Because the user never receives a route to your private network, they can't reach or discover anything they weren't explicitly permitted. ### How is this different from a traditional VPN? A traditional remote access VPN authenticates a user onto a network and relies on firewall rules to limit them from there. Access Server as a Zero Trust Application Broker authenticates a user to a specific application and never creates a network path to anything else, so least privilege is enforced by the architecture rather than by downstream rules. ### How do I configure applications? Applications can match an exact domain (app.example.com), a wildcard domain (*.example.com) that covers all subdomains, or a wildcard TLD (*.com). ### How do I authorize applications for users? You decide who gets what by writing domain rules at whichever level makes sense. Give everyone access to a shared tool with a global rule, hand a specific app to one team through a group rule, or grant a single person access on their own. The levels stack, so a broad rule for the whole company can coexist with tighter ones for individual teams, and anyone affected reconnects automatically to pick up the change. ### What do I need to get started? You'll need: - Access Server 3.1.0 or newer - Admin Web UI access - DNS server proxy enabled on your Access Server - One or more users or groups configured ### Can I restrict the protocol and port used to access the application? No. When applications are configured in access rules, the port and protocol cannot be specified. ### How do I configure location and device checks? You can set these checks either at your identity provider, using its conditional access policies, or on Access Server itself with a plugin. Browse the [plugins page](https://openvpn.net/as-docs/plugins.html) to learn more. ### Does it work with my identity provider and MFA? Yes. Access Server supports SAML, LDAP, and RADIUS, so you can connect it to Okta, Microsoft Entra ID, Google Workspace, or your existing directory, and users sign in with the corporate credentials and MFA they already have.