You publish on-premises applications by placing the connector inside the network, exposing only the application through the proxy, and enforcing authentication and access policy in Microsoft Entra ID. Protect the app with MFA and least privilege, restrict who can reach it, and test header, session, and sign-in behaviour before going live.
How Entra Application Proxy fits into secure publishing
Microsoft Entra application proxy is a control layer for making internal web applications reachable without placing them directly on the internet. The connector establishes the outbound path from inside your network, while Entra ID handles authentication and policy enforcement before a request reaches the app. That separation matters because the proxy should narrow exposure, not become a second place to manage trust or session logic.
Secure publishing starts by treating the application as the protected asset and the proxy as the enforced front door. The application should remain internal, with only the proxy endpoint exposed externally, so you are not extending network reachability more than necessary. That design is strongest when the app already has clear authentication boundaries, predictable headers, and well-defined session behaviour.
The ZTNA pattern is the right mental model here: publish per application, mediate access through identity, and avoid broad network-level exposure. For teams planning that pattern end to end, the ZTNA Guide is the most direct companion because it covers outbound connectors, per-application policy, and application-level access.
What to secure before users reach the app
Authentication and authorization should be decided in Entra ID, not left to a loosely configured application path. That means requiring MFA where appropriate, limiting access with conditional access and assignment scope, and ensuring the published app is only available to the users or groups that genuinely need it. If the app depends on roles, verify that the authorization model still works when the request originates through the proxy rather than from an internal browser session.
Connector placement also deserves attention. The connector sits inside the trusted network boundary, so its host must be hardened, monitored, and limited to the minimum necessary outbound communication. The proxy model reduces inbound exposure, but it does not remove the need to protect the connector host, the app server, and any backend services the app calls.
Because Entra application proxy depends on identity configuration, hybrid directory hygiene and privileged access discipline are part of the publishing workflow. The Active Directory and Entra ID Hardening Guide is useful here because it covers hybrid identity, privileged groups, delegation, and the access paths that often determine whether a publishing design stays tight or becomes overexposed.
How to validate behavior before going live
Testing should go beyond simple sign-in success. Confirm that headers are preserved or rewritten as expected, that the application still enforces session timeout correctly, and that sign-in prompts occur only when intended. Pay particular attention to apps that use redirects, absolute URLs, WebSocket-like patterns, or legacy authentication flows, because those are the cases most likely to break when placed behind a proxy.
Also validate whether the published path changes how the app interprets client IP, scheme, host, or forwarded headers. A secure deployment can still fail operationally if the app trusts a header it should not trust, or if the proxy introduces a mismatch that breaks logout, CSRF handling, or downstream API calls. In practice, those issues are easier to catch in staged testing than after external users start hitting the proxy.
For teams that want a deeper identity and access lens on role assignment, app permissions, and least privilege around Entra workloads, the Azure RBAC and Service Principals Guide is a strong fit because it focuses on access scope, service principal hygiene, and privilege boundaries that commonly affect published application estates.
Risk and Threat Considerations
Publishing through a proxy reduces direct exposure, but it still creates risk if authentication is weak, the app is over-shared, or the connector host is not well controlled. The main failure mode is that teams assume the proxy alone makes the app safe, when the real exposure often comes from excessive access, broken header trust, or lingering internal attack paths.
Failure mechanism: An attacker can abuse weak policy, stolen credentials, or misconfigured access scope to reach an internal application that was meant to remain tightly limited, then leverage the application’s own session or header handling to deepen access.
Impact: The result can be unauthorized application use, data exposure, session abuse, or a pivot into internal services that were never intended to be internet-reachable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Entra proxy publishing depends on strong user authentication before app access. |
| AC-6 — Least Privilege | Publishing should restrict access to only the users and groups that need the app. | |
| IA-5 — Authenticator Management | The design relies on protecting sign-in material and enforcing MFA-backed access. | |
| Recommendation — Enforce strong user authentication before allowing access to the published application. Limit published-app access to the minimum set of authorized users and groups. Manage authenticators carefully and rotate or revoke them when exposure is suspected. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Entra sign-in and access policy depend on federated authentication behavior. |
| Recommendation — Validate federation, token handling, and login flows before exposing the app. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Secure publishing requires tightly scoped access assignments and review. |
| Recommendation — Review who can reach the application and remove unnecessary access paths. | ||
Practitioner Guidance
What to verify: Confirm that the app is not relying on the proxy for security decisions it should make itself, especially around authorization, session expiry, and any trust placed in incoming headers. Also verify that access policies are group-based and reviewed, not tied to ad hoc individual assignments.
Common mistake: Treating the publishing project as a networking task only. The secure outcome depends on identity policy, app configuration, and backend containment working together, not just on installing the connector.
Decision rule: If the application cannot tolerate header rewriting, ambiguous client identity, or a browser-mediated sign-in flow, fix those dependencies before broad rollout. If the app can tolerate them only with exceptions, keep the rollout narrow and explicitly documented.
Practitioner takeaway: Secure publication is achieved when the proxy narrows reachability, Entra ID governs access, and the application is proven to behave correctly under that access path, without hidden trust assumptions.
Related resources from NHI Mgmt Group
- How should security teams extend Microsoft Entra ID to legacy on-premises applications without rewriting every app?
- How do you apply least privilege to application permissions in Microsoft Entra ID?
- How do you manage and evaluate application consent requests in Microsoft Entra ID?
- How do you restrict a Microsoft Entra application to a specific set of users?