29. 09. 2025 Davide Spano Azure, Microsoft

Secure Access to Applications with Azure

One overarching goal in the IT industry is to enable authorized users to securely access company resources. The implementation that fulfills this general requirement will depend on several factors, some of which will become clear as the topic unfolds.

This article gives a logical and historical overview of what Secure Access is, the use cases and implementation options that exist to satisfy the needs of organizations to share information with their users.

The Corporate Network

The most traditional and dated approach is that of a closed corporate network, where all users and resources are located within a controlled network perimeter that is typically labelled as “on-premises”.

Active Directory is one such implementation, and it is, in fact, a bundle of services, one of which is Secure Access.

Active Directory (AD) is designed to implement secure access through built-in features such as:

Authentication: AD uses protocols like Kerberos and NTLM to verify user identities before granting access to network resources.
Authorization (Access Control): Access Control Lists (ACLs) are used to define permissions for user accounts and security groups, allowing or denying actions like read, write, or modify on directory objects.
Encryption: AD supports encryption for sensitive data and communication, such as Kerberos tickets and IPsec for replication traffic, to protect credentials and data in transit.
Directory Auditing: AD provides auditing capabilities to track user activities and changes within the directory, which is crucial for detecting suspicious behavior and ensuring compliance.

In this scenario, which was already mainstream a few decades ago, all users and the resources they can access are on the same privately owned infrastructure and, in the simplest case, there is no requirement to grant access to these resources from outside the business-controlled network perimeter.

One thing that’s perhaps worth noticing is that Active Directory Domain Services is technically only one product suite implementing this older paradigm; there were, and still are, some competitors to AD, but Active Directory Domain Services has been, for a long time, the unquestioned market leader and one of the reasons for the success of Microsoft as a business overall.

This is clearly a thing of the past, but it is a conceptual stepping stone that will be referred to as we explore the timeline with its changing requirements. It will be useful to assess how the needs of organizations have changed over time as a result of the inevitable technological innovation.

The advent of the Internet

In the 1990s, businesses began using the internet extensively, which caused a significant paradigm shift with new requirements, some of which are most relevant to the present discussion:

Enterprises needed a way to provide employees and partners with secure access to the company’s internal network and applications from various locations.
Businesses needed a secure way to send sensitive information across public networks.

The Proxy Architecture

In the early 1990s, proxies were introduced as one architectural solution to the problem of external access to corporate resources. A proxy is a server and dedicated software layer that acts as a gateway between the internet and users.

It provides two main functions:

IP obfuscation: The proxy replaces the IP address of the source of a request with its own before sending the data to its intended destination on the public web.
Network Firewalls: Proxies can be configured to filter and block traffic according to specific rules based on content, web services, or other traffic attributes such as geo-location.

The Proxy Architecture represents the simplest solution to the problem of access to the organization from the internet. However, as simple as it sounds, its practical implementation always comes with a series of attached security requirements that cannot be dropped. In particular, it is often combined with a DMZ (Demilitarized Zone), which acts as a security buffer between a public network and a private internal network, and adds a significant amount of complexity and administrative costs, even to the simple Proxy solution.

The complexity arises from the need for additional network configuration, management, and potentially dual firewalls, and the increased cost is due to the additional hardware and software required to establish and maintain this extra layer of security.

The Virtual Private Network Architecture (VPN)

In the mid-1990s, the Virtual Private Network Architecture (VPN) was developed alongside the Proxy-based architectures as a solution to the problem of remote and public access, applicable in the presence of the additional end-to-end requirement of traffic encryption.

The data transferred between the user and the network is encrypted and stays within the VPN tunnel.
Security admins can see that the user has accessed the network, but they cannot see what applications or resources the user has accessed.
Remote users gain access and are within the network perimeter; they often can access everything on the network just as if they were located on premises.

The VPN design routes a device through a private server to obfuscate the data and its origin, using a combination of authentication, encryption, and tunnelling, in order to form a stable, permanent and secure connection.

Proxy vs. VPN

A proxy is a lightweight gateway between the internet and users, implementing IP obfuscation and firewall functions. On the other hand, VPN traffic runs through an encrypted tunnel through the user’s device, making VPNs an effective solution for ensuring comprehensive network-level security. The distinctive trait of the VPN solution is the encryption of the data traffic transmitted through it. This may be an essential requirement for organizations that deal with sensitive data and can be used as a discriminant to decide which of these two options should be used.

However, in all cases where access may not need full traffic encryption, the following aspects should be considered when making the implementation choice.

A VPN requires more effort during setup, administration and maintenance than a Reverse Proxy.

Setup and Maintenance: A VPN requires client-side software installation, configuration, and constant updates for every user device. The reverse proxy is a server-side tool with easier, server-centric configuration and no client-side software needed. It might require a complex initial setup for its web server functions, but its ongoing maintenance is minimal when compared to a VPN, which is more involved due to managing user access, network security, and software on multiple individual devices.
Centralized vs. distributed Maintenance: with the Proxy, maintenance primarily involves managing the server, making it less distributed than VPN maintenance, which requires configuring software down to the end user.
Network-Level Access: the VPN works at the operating system level, redirecting all internet traffic over any protocol, which can involve more complex configuration and troubleshooting across different devices and networks. A reverse proxy typically handles only HTTP/S traffic and does not need to manage diverse traffic types for individual users.

The Advent of the Cloud

The introduction of cloud technologies might be considered the next major paradigm shift in the recent history of the Information and Communication Technology (ICT). There is much to say about the radical changes that this event has brought to the industry, but to limit the scope to the present discussion, it’s perhaps most straightforward to consider that one big factor is that the information that describes the organization’s users has moved from being completely on-premises to cloud directories.

In the context of Microsoft Azure, that means that the new standard is to catalogue and manage users in Microsoft Entra ID. Among other things, Microsoft Entra ID may be described as a very reliable, cloud-based directory service loaded with a myriad of security services that would be hard to come by in a completely on-prem context at the same cost.

The following is a short rundown of the advantages of a cloud directory service, such as Microsoft Entra ID, for any organization.

Cloud-First Environments: Entra ID is designed to manage identities and access for cloud applications, SaaS apps, and the entire Microsoft 365 ecosystem, which AD is not built for.

Infrastructure-Free: Entra ID is a fully cloud-hosted service, eliminating the need for on-premises domain controllers, servers, or associated infrastructure management and maintenance.

Enhanced Security Features:

Conditional Access: Entra ID allows administrators to define granular policies that control access based on user, device, location, and risk, providing more dynamic and intelligent security.

Modern Authentication: It supports advanced authentication methods such as multi-factor authentication (MFA) and passwordless options, which are more secure than traditional AD methods.

Intelligent Security: Entra ID includes intelligent password protection, smart lockout, and the ability to block common password phrases, improving security posture.

Mobility and Remote Work: It’s ideal for managing mobile devices and supporting remote users, providing seamless access to cloud resources from anywhere.

Simplified User Experience: Users benefit from a self-service password reset (SSPR) system, which reduces support costs and administrative burden.

Integration with Modern Applications: Entra ID is optimized for integration with modern web and SaaS applications, offering more flexibility than AD’s reliance on protocols like Kerberos for on-prem systems.

Hybrid Flexibility: While Entra ID is for the cloud, it also integrates with on-prem AD through Microsoft Entra Connect, enabling a hybrid approach that extends identity management to the cloud.

Microsoft Entra Application Proxy

Considering that the predominant scenario nowadays sees organizations leveraging cloud-based identity services such as Microsoft Entra ID, it’s a legitimate question to ask: what relation exists between this adoption and the former models of access to corporate resources?

There is still a need for the users catalogued in Microsoft Entra ID to access business resources that may be running completely in the cloud, or completely on-premises. For the former types, there’s always integration between them and Microsoft Entra ID; therefore, there is no technical problem in this case. However, businesses may still need to run on-prem software that must be accessed by employees, users and external collaborators from the Internet and for which shifting to the cloud to leverage the natural integration with Microsoft Entra ID may be impractical, impossible or simply too risky and expensive.

For those on-prem HTTP(S) based applications, Microsoft Entra application proxy offers a very convenient and cost-effective way out, saving the business from having to implement its own VPN or Proxy architecture, inclusive of firewalls and DMZ. Microsoft Entra Application Proxy provides Single Sign-On (SSO) combined with Conditional Access.

The process involves registering an application in Microsoft Entra and installing a lightweight connector on-premises or any network owned and managed by the organization that has line-of-sight to the server on which the application runs. It also implies that Microsoft Application Proxy can also be used to access, with SSO, applications on Azure or other clouds, and not only on-premises, with the only real requirement being that the application must be a web application:

A user is directed to the Microsoft Entra sign-in page after accessing the application through an endpoint.
Microsoft Entra ID sends a token to the user’s client device after a successful sign-in.
The client sends the token to the application proxy service. The service retrieves the user principal name (UPN) and security principal name (SPN) from the token. The connector pulls the application proxy for any authentication requests, which requires only an outbound connection; therefore, no ports need to be opened on the service network!
The connector performs single sign-on (SSO) authentication on behalf of the user.
The connector sends the request to the on-premises application.
The response is sent through the connector and application proxy service to the user.

In summary, to best outline the business case for Microsoft Entra application proxy, we could say that, if one or more of the following conditions are true, then this might be the right solution:

The business owns web applications that must run on-prem or on other clouds.
The business manages the networks on which the application servers and the internal authorisation servers are located.
The business already uses Microsoft Entra ID as a directory service for all its users.
The business does not want to create, extend and manage a VPN for the users of the applications.
The business does not want to create, extend and manage its Proxy architecture.
It is important to provide SSO quickly and at a low implementation cost.
Security features as MFA and Conditional Access are highly desirable.

The cost factor may be important in the decision process, and it’s clear that this aspect requires a mindset shift as well, from the overall setup and maintenance cost of traditional on-prem implementations to the per-user license model that is more typical for cloud-based services:

With Microsoft Entra ID P2 $9.00 per user/month, any number of applications can be accessed, and advanced features, part of premium identity protection and governance capabilities, can be leveraged, such as Microsoft Entra ID Protection, which includes Conditional Access.

Microsoft Entra ID P1 $6.00 per user/month gets very close, as it still grants SSO and MFA, but it will not allow Conditional Access, among other things.

The Zero Trust Network Access (ZTNA) Approach

Traditional security models employ a perimeter-based approach, which trusts anything inside the network and focuses security efforts on the perimeter; the VPN architecture is a typical example. However, the introduction of the cloud has extended the perimeter to any network, thus making the traditional perimeter-based security model impractical and eventually impossible.

The alternative is a new security model (ZTNA) that builds entirely on the concept of secure identities and secure access; it aims at completely replacing the VPN architecture. ZTNA continually verifies every access request regardless of location, user, or device. It assumes that every user, device, or network segment is a potential threat, and enforces strong, identity-centric access controls at every stage.

Is Microsoft Entra Application Proxy a Zero Trust Network Access solution?
Why can’t Microsoft Entra Application Proxy be considered a Zero Trust Network Access solution?

Microsoft Entra Application Proxy cannot be considered a full Zero Trust Network Access (ZTNA) solution because:

It focuses on application-level access rather than providing general network access
It does not support continuous validation of the user’s security posture and device compliance, which are necessary for ZTNA.

Microsoft Entra Application Proxy is the first step in the new direction of the IT industry. It suffices when the organization only needs to provide web-based access to on-premises apps or managed cloud apps and secure remote access without continuous granular access control over private networks. It’s also applicable in cases of on-premises applications that rely on legacy authentication methods, as it acts as a bridge between them and modern Microsoft Entra ID authentication ( SSO + MFA + Conditional Access ).

Microsoft Entra Application Proxy is relevant, as:

It can be used by some organizations as a transition solution towards a full ZTNA solution that not only solves the problem of access to on-prem legacy and modern web apps, but also that of replacing the VPN security model with something better suited to the cloud-based reality.
It is built on the same technology used in the Microsoft Global Secure Access (ZTNA) and can therefore be considered a precursor of the latter.

Global and Private Secure Access

The last step in the evolution timeline ends with the Microsoft Global Secure Access (ZTNA), which was introduced in the previous paragraph. With GSA, it’s possible to do all that can be done with Microsoft Entra Application Proxy and much more; thus it’s worthwhile to focus on the added value GSA brings when compared to its predecessor.

Global Secure Access is an umbrella term for Microsoft’s Security Service Edge (SSE) solution; it includes:

Microsoft Entra Internet Access for securing access to the Internet and SaaS apps.
Microsoft Entra Private Access for securing access to private resources, such as on-premises applications. It focuses specifically on protecting internal resources by replacing traditional VPNs with a Zero Trust approach.

From the operational point of view, Microsoft Entra Private Access is similar to Microsoft Entra Application Proxy, as it requires installing the Microsoft Entra private network connector on one or more Windows servers within your private network; these do not have to be the application servers, as long as the application servers are in the network line-of-sight. This lightweight agent acts as a bridge, establishing a secure, outbound-only connection from your on-premises environment to the Microsoft Entra cloud service, enabling access to your private applications without requiring inbound firewall rules.

Once this is done, the applications can be discovered and individually configured for security within the connector. Finally, each access request to the exposed service will be authenticated by Microsoft Entra ID and continuously evaluated over time through the integrated Microsoft Entra ID tools and services to this end.

It’s therefore possible to conclude that Microsoft Entra Private Access is an identity-centric, ZTNA-compliant and fully managed implementation of the Proxy Architecture, which brings great value. However, the advantage of Microsoft Entra Private Access goes a step further, as it also completely replaces the need for a VPN.

For clients, a lightweight, fully Microsoft-managed Global Secure Access Client exists. Remote workers install the Global Secure Access Client, which connects them securely to the resources they need without the need for a traditional VPN client. The client will then be tailored for secure access with the mechanism of Conditional Access policies, which are centrally governed in the Microsoft Entra ID portal.

Considering all the provided information, one is left to wonder which technology makes the most sense. One way is to consider the implementation and maintenance costs and ask: What is the price difference between Microsoft Entra Application Proxy and Global Secure Access?

Microsoft Entra Application Proxy is a feature requiring an Entra ID P1 or P2 license as explained in detail earlier in this document:

Microsoft Entra ID P2 $9.00 per user/month
Microsoft Entra ID P1 $6.00 per user/month

Microsoft Entra Private Access can be licensed in various ways:

Microsoft Entra ID P1 or P2 is a prerequisite to use Microsoft Entra Private Access.
It can be licensed separately for around $5 per user/month.
It can be licensed in bundles such as Microsoft Entra Suite Subscription or some Microsoft 365 plans, such as the Microsoft 365 E5 plan.

Therefore, Microsoft Entra Private Access implies additional cost over the basic Microsoft Entra Application Proxy, and each organization should evaluate whether the features added by the former are good value for money and compensate for the cost savings that are realized by replacing the in-house VPN with the fully managed Microsoft Entra Private Access VPN replacement. Additionally, in cases where license bundles such as Microsoft 365 E5 plans are a viable option, users would also benefit from Microsoft Internet Access.

With Microsoft Internet Access, the same Zero Trust Network Access (ZTNA) principles are extended from the case of access to web-based private apps to any other Software as a Service (SaaS) over the entire Internet.

DNS and Link Translation Considerations

Finally, it’s worth noting this last aspect, which can be dealt with jointly for Microsoft Entra Application Proxy and Microsoft Entra Application Proxy, as these share the underlying technology.

When a web application is published on-premises, it may contain external and internal hardcoded links in its pages. The external links will work as normal, but the internal links will break when the application is exposed to external users through the proxy service.

Multiple solutions are available to solve this problem, the most straightforward of which is to simply configure a custom domain for the proxy. By matching the internal and external URLs through a custom domain, complex link translation is no longer necessary, which also reduces performance, and in some cases fails for JavaScript-generated URLs or other complex scenarios.