We have a growing collection of internal web apps built quickly with AI-assisted coding tools, so we assume the application code may contain ordinary security mistakes and should not be trusted as the only security boundary. The apps currently run in Docker containers on-premises, with a move toward Kubernetes, and use Entra ID through OIDC for single sign-on. Employees want mobile access from a mixture of Intune-managed devices and unmanaged BYOD devices, where installing an agent, VPN client, or certificate everywhere is not practical. Our edge consists of a firewall, DMZ, load balancer, and WAF. We have Microsoft 365 E5 licensing, but would prefer to keep application traffic within our own infrastructure instead of relying on a third-party cloud proxy. The solution needs to work from a mobile browser, or through a custom app if that is more appropriate, while remaining manageable for a small team. How would you design the pre-authentication layer, network segmentation, device and identity checks, and protection against vulnerable application code? Production experience and lessons from approaches that failed would be especially useful.
5 Answers
A self-hosted approach could use a reverse proxy in the DMZ, terminating TLS and authenticating against Entra through OIDC, then forwarding only to private application networks. Put each application or trust group behind separate firewall policies rather than giving the proxy broad access to the container network. Managed devices can receive stronger device-compliance and app-protection policies through Intune, while BYOD should be treated as untrusted: require MFA, limit access to the minimum required apps, avoid broad network connectivity, and use short-lived sessions with careful cookie and download controls.
Another workable pattern is a mesh-VPN or ZTNA overlay that publishes only selected services and keeps the apps off the public edge. It can be convenient for managed devices, but browser-only BYOD access and user onboarding need to be tested carefully; a solution that requires a client will not meet the BYOD requirement by itself. I’d avoid making users remember ugly internal URLs and would provide normal DNS names, while keeping public DNS and firewall exposure limited to the access gateway.
For the lowest operational burden, Entra Application Proxy is worth considering. It handles the external publishing and pre-authentication without requiring agents or certificates on BYOD phones, and it fits naturally with existing Entra SSO and conditional access. The tradeoff is accepting a Microsoft-hosted access path rather than keeping the entire publishing layer on-premises. I’d still place the applications behind internal segmentation and treat the connector and identity configuration as part of the security boundary.
That’s a practical option, but the decision really comes down to whether the requirement to avoid third-party proxying is firm. If it is, an internally hosted reverse proxy or ZTNA product is a better fit, with the added responsibility of operating and securing that access layer yourself.
Cloud-hosted tunnels and access proxies are easy to deploy because they avoid inbound firewall rules and can combine Entra authentication with application-specific policies. They’re a reasonable small-team choice if the traffic-routing requirement can be relaxed. I would compare them against self-hosting based on data sensitivity, outage behavior, logging needs, and vendor dependency rather than assuming the free or inexpensive option is automatically secure. In either case, use defense in depth: WAF rules, secure headers, rate limits, vulnerability scanning, image signing, least-privilege containers, centralized logs, and independent tests of every app’s authorization.
I’d put an identity-aware reverse proxy or ZTNA gateway in front of the load balancer and make the applications completely unreachable from the public internet. The gateway should authenticate with Entra ID before forwarding anything, enforce group-based access, apply MFA and conditional-access policies where possible, and pass only the identity claims the application actually needs. Keep the apps in separate network segments and restrict the proxy to the specific service ports. This reduces the impact of an app accidentally exposing an unauthenticated route, although it does not replace secure coding, authorization checks inside the app, patching, logging, and container hardening.
Usability is the main risk with this design. If the workforce is not technically inclined, client installation, unusual URLs, or repeated VPN steps will create support work. A browser-based gateway with normal company domains is usually easier for BYOD users.