Azure AD Application Proxy and the NHI governance gap

At a glance

What this is: Azure AD Application Proxy extends remote access to on-premises applications through Azure AD, but the article shows that cookies, timeouts, and URL translation create governance decisions that affect trust boundaries.

Why it matters: IAM and IGA teams need to treat Application Proxy as an access-governance pattern, because session persistence and backend translation can alter who can reach legacy applications and for how long.

Context

Azure AD Application Proxy is a brokered access pattern for on-premises web applications. It uses a cloud service, an on-premises connector, and Azure AD sign-in tokens to publish internal applications through external endpoints.

The security gap is not whether the tunnel works. It is whether identity, session, and application-boundary assumptions still hold once access to a legacy web app is mediated by token exchange, cookie behaviour, and backend forwarding.

That makes the topic directly relevant to non-human identity governance because connectors, tokens, and session artefacts are part of the access path that must be governed alongside the user identity that initiates it.

Key questions

Q: What breaks when Azure AD Application Proxy sessions use persistent cookies?

A: Persistent cookies can keep remote access alive after the browser closes, which widens the exposure window for unattended devices, shared endpoints, and delayed revocation. For sensitive applications, that means the session policy becomes part of the access decision. Teams should only permit persistence where the business use case truly requires it and where compensating controls are in place.

Q: Why does brokered app access change governance requirements for IAM teams?

A: Because authentication is no longer the only control point. The proxy, connector, cookies, backend timeouts, and translated application responses all influence how long access remains valid and what the remote user can reach. IAM teams therefore need to govern the whole published path, not just the Azure AD sign-in event.

Q: How should teams evaluate backend timeouts for published web apps?

A: They should compare the timeout to the application’s real transaction length, user role, and sensitivity of the published workflow. If a backend process legitimately runs longer than the front-end session assumptions, the timeout can create either broken user experience or unnecessary exposure. The right setting is the one that matches the app’s risk profile.

Q: When should access reviews include applications published through Azure AD Application Proxy?

A: Whenever the published app exposes business-critical workflows, regulated data, or separation-of-duties sensitive functions. A proxy does not reduce the need to certify access, because the underlying entitlements still determine who can reach the application and what they can do once inside. Include these apps in the same review cycle as other privileged access paths.

Technical breakdown

How Azure AD Application Proxy brokers access to internal apps

Azure AD Application Proxy publishes an external HTTPS endpoint that forwards requests to an internal application through an on-premises connector. Azure AD issues the sign-in token, the service validates identity context, and the connector relays the request to the backend app. This creates a layered trust chain: the user authenticates to Azure AD, but the application still depends on connector behaviour, application configuration, and the session artefacts carried between them. The result is not a simple reverse proxy pattern. It is an identity-mediated access bridge that inherits both identity governance and application-session constraints.

Practical implication: govern the endpoint, connector, and application as one access path, not as separate controls.

Why cookies and timeouts change the trust boundary

Application Proxy can use HTTP-only, secure, and persistent cookies, and each option changes how long a session remains usable and where it can be replayed. Persistent cookies are especially material because they allow the session to survive browser closure, which is convenient for rich clients but increases exposure if device or session control is weak. Backend timeout settings matter too, because longer-lived transactions can keep application access active after the front-end session model would otherwise have ended. In practice, the proxy is not just a transport layer. It is part of the session governance model.

Practical implication: align cookie persistence and timeout settings with the sensitivity of the published application.

How URL translation affects backend isolation

URL translation in headers and application body is a compatibility feature for split DNS and internal links, but it also changes how internal application paths are exposed to the remote client. When the published app assumes a private namespace or original host header, translation can preserve function while blurring where trust boundaries sit between the external client and the internal resource. That is useful operationally, but it also means security teams need to understand whether translated links, headers, and responses leak assumptions about internal structure or bypass application expectations. Compatibility settings can therefore become governance settings.

Practical implication: review translation settings against the application’s internal namespace, header handling, and exposure model.

NHI Mgmt Group analysis

Azure AD Application Proxy is a governance control point, not just a connectivity feature. The article shows that access is mediated by Azure AD tokens, connectors, and browser cookies, which means the trust decision does not end at sign-in. Once an internal web app is published externally, the access path itself becomes part of the identity perimeter. Practitioners should treat this as governed remote access, not infrastructure plumbing.

Persistent session artefacts are the real governance risk in proxy-mediated access. The article’s cookie discussion is the clearest signal that access duration and replayability matter as much as authentication strength. When a session survives browser closure, governance has to account for device sharing, unattended endpoints, and delayed revocation. The implication is that session policy becomes an access-control decision, not a user-experience setting.

Application Proxy exposes a classic NHI-style oversight: the control plane and the application plane can drift apart. Azure AD may enforce sign-in conditions, but the backend application still depends on its own timeout, header, and cookie assumptions. That separation can leave legacy apps accessible in ways the identity team did not explicitly intend. The practical conclusion is that published applications need joint review across IAM, app owners, and GRC.

Fine-grained access governance becomes more important when remote publishing replaces direct network access. Pathlock’s discussion of separation of duties and user access reviews points to the right operational direction: published applications should not inherit broad, static access simply because they sit behind Azure AD. The governance challenge is to preserve application-level entitlements and reviewability even when access is brokered through modern identity controls.

Named concept: brokered session governance. This article illustrates that a proxy can move the control boundary from network reachability to session behaviour, cookie persistence, and application translation rules. That is a distinct governance pattern, because the access decision now spans identity, session, and backend response handling. Practitioners should recognise that brokered sessions need their own review model, not just a sign-in policy.

What this signals

Brokered session governance: once a remote application is published through an identity-aware proxy, the control problem shifts from network reachability to the behaviour of sessions, cookies, and translated responses. That means access governance has to include how long a published session remains usable and whether the backend app still sees the same trust context it expects.

Published applications also need explicit ownership for review and offboarding because the proxy can hide how access is actually granted. If IAM, application, and GRC teams do not jointly understand the publication path, certification decisions become detached from the real entitlement model.

For practitioners

• Review persistent cookie use Decide whether published applications truly need browser-persistent sessions, and restrict that setting to the smallest set of rich-client use cases that cannot operate without it.
• Align backend timeout settings Match backend application timeout values to the sensitivity and transaction length of the application so remote sessions do not outlive the intended use window.
• Validate URL translation against internal namespace design Check whether header and body translation preserve or distort the application’s expected host headers, internal links, and split DNS assumptions before broad rollout.
• Pair proxy publishing with access reviews Include externally published applications in entitlement reviews, especially where the proxy exposes business-critical or Segregation of Duties-sensitive workflows.
• Treat connectors as governed access infrastructure Inventory connector groups, ownership, and availability so published apps have explicit operational accountability and failover expectations.

Key takeaways

• Azure AD Application Proxy does not just extend connectivity. It changes the access-governance model by inserting identity, session, and translation controls between the user and the internal app.
• Persistent cookies and backend timeouts are not minor configuration details. They determine how long remote access survives and whether a session can outlast the intended trust boundary.
• The safest operating model is to review published applications as governed access paths, with explicit entitlement review, connector ownership, and session-policy decisions.

Key terms

• Azure AD Application Proxy: A brokered access service that publishes internal web applications through Azure AD and an on-premises connector. It lets remote users reach legacy applications without a direct VPN, but it also introduces identity, session, and boundary decisions that must be governed as part of the access path.
• Persistent Cookie: A persistent cookie is a session cookie that remains valid after the browser closes until it expires or is explicitly removed. In remote access designs, it can improve usability, but it also increases the chance that a reused session becomes standing access if the organisation does not enforce compensating controls.
• URL Translation: A compatibility feature that rewrites headers or links so applications built for an internal namespace can function through a public endpoint. It preserves reachability, but it can also mask assumptions about host headers, internal paths, and the boundary between external clients and internal services.
• Brokered Session: A brokered session is an access path in which a gateway or intermediary issues or mediates credentials on behalf of an agent. It reduces direct credential handling by the agent, but the broker still has to enforce scope, masking, and auditability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.