Azure AD Application Proxy and the NHI governance gap

At a glance

What this is: Azure AD Application Proxy brokers remote access to on-premises web applications through Azure AD, connector services, and token exchange, with security outcomes shaped by cookie and session choices.

Why it matters: IAM and NHI teams need to treat the proxy path as an identity control plane, because mis-scoped sessions, cookies, and connector placement can widen the blast radius of remote access.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Pathlock's Azure AD Application Proxy workflow and best practices guide

Context

Azure AD Application Proxy is a remote access pattern that exposes internal web applications through Azure AD rather than placing them directly on the internet. For IAM and NHI practitioners, the important issue is not only user sign-in, but the identity and session assumptions carried by connectors, cookies, tokens, and backend translation.

That matters because the proxy model shifts trust into a chain of services and credentials that must remain tightly governed. The article’s starting point is typical for enterprise teams that need remote access, but the real security question is how much standing access, session persistence, and backend trust they are prepared to tolerate.

For the underlying identity model, see the Ultimate Guide to NHIs , What are Non-Human Identities, which frames service accounts, tokens, and workload identities as governed assets rather than implementation details.

Key questions

Q: How should security teams govern application proxy access for internal web apps?

A: Treat application proxy access as part of the identity control plane, not just remote connectivity. Define which applications may be published, limit connector scope, require short-lived sessions where possible, and tie access review to the exposed application and its backend path. The goal is to reduce standing access and make revocation immediate when risk changes.

Q: When does persistent cookie use create more risk than value?

A: Persistent cookies become risky when the session outlives the task, the device is not trusted, or revocation is slow. They can preserve access after a browser closes, which is convenient for some workflows but dangerous for sensitive apps. Use them only when the business case is explicit and monitoring can detect reuse quickly.

Q: What is the difference between remote access and least-privilege proxy publishing?

A: Remote access focuses on making an application reachable from outside the network. Least-privilege proxy publishing limits which apps are exposed, which connectors can reach them, how long sessions last, and what cookie behaviour is allowed. The second model is narrower and more defensible for NHI governance because it constrains the full access path.

Q: Should organisations include proxy connectors in access reviews?

A: Yes. Proxy connectors are part of the trust chain that carries identity from Azure AD to the internal application, so they should be reviewed like other privileged infrastructure. If the connector can reach more than one sensitive app, or if its host permissions are broad, the organisation is accepting hidden exposure that belongs in the review process.

Technical breakdown

How Azure AD Application Proxy brokers identity and session flow

Azure AD Application Proxy works by placing an internet-facing service in front of internal applications and using a connector on-premises to reach the backend. The user authenticates with Azure AD, receives a token, and the proxy forwards the request through the connector to the internal app. The design reduces direct exposure of the application, but it also creates a chain of trust across cloud service, connector, and application server. That means the security boundary is no longer a single network perimeter. It becomes a sequence of identity assertions, session handling decisions, and connector permissions that must all be controlled as part of NHI governance.

Practical implication: Treat the connector and token path as governed NHI infrastructure, not just a remote access convenience.

Cookie handling and session persistence in proxy-based access

The article highlights HTTP-only, secure, and persistent cookies because each changes how long a session remains usable and how easily it can be stolen or replayed. HTTP-only helps reduce script access, secure cookies limit transmission to TLS channels, and persistent cookies extend usability across browser closures. In NHI terms, this is a session-lifetime problem. A remote access pattern that depends on durable cookies can quietly create standing access if expiry, revocation, and device trust are weak. The issue is not just authentication strength at login. It is whether the session remains appropriately bounded after the user has authenticated once.

Practical implication: Align cookie lifetime with task scope and revoke persistent session paths where business need is weak.

URL translation, backend timeouts, and hidden trust expansion

URL translation and backend timeouts appear operational, but they have security consequences. URL translation is used when internal and external namespaces differ, which can mask how requests move between public and private endpoints. Longer backend timeouts can also keep sessions alive while a request waits on downstream systems. Both mechanisms can improve usability, yet they also widen the window in which a session, token, or connector remains relevant. For NHI practitioners, that matters because long-lived or loosely translated application paths are easier to misuse if entitlements, monitoring, and revocation are not aligned with the access pattern.

Practical implication: Review translation and timeout settings as part of entitlement design, not as purely application tuning.

Threat narrative

Attacker objective: The attacker aims to turn a remote access proxy into durable entry to internal applications and their associated identities.

1. Entry occurs through a proxy-exposed application path that relies on Azure AD sign-in, connector reachability, and session cookies rather than direct network exposure.
2. Escalation can follow if persistent cookies, weak backend boundaries, or overbroad connector permissions let an attacker reuse a session or move laterally into internal applications.
3. Impact is unauthorized access to on-premises business applications and their linked identity workflows, especially where access review and revocation are slow.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Proxy-based access is now an NHI governance problem, not just a publishing choice. Azure AD Application Proxy reduces direct exposure, but it also concentrates trust in connectors, tokens, cookies, and backend session rules. That makes it part of the non-human identity attack surface, not merely a networking feature. Practitioners should govern it with the same discipline they apply to service accounts and secret-bearing workloads.

Persistent session design is a form of standing privilege. If access remains valid after the browser closes, the organisation is effectively preserving a reusable credential path. That is acceptable only when the business need is explicit and compensating controls are real. Otherwise, persistent cookies undermine zero-standing-privilege goals and make offboarding slower than the exposure window demands.

Identity proxies expose the runtime governance gap. The named concept here is the runtime governance gap: the space between a successful login and the continued authority of the resulting session. Azure AD Application Proxy is useful precisely because it hides infrastructure complexity, but that same abstraction can hide excessive session duration, translation shortcuts, and weak revocation hygiene. Teams should measure whether runtime controls match the access model they think they have.

Connector placement and timeout settings should be treated as control decisions. Connector groups, long backend timeouts, and translation settings are often handled by application teams, yet they define how long a request can persist and where trust is extended. The field should stop treating these as implementation details and start treating them as governance inputs. That is where NHI and IAM teams should assert ownership.

Application Proxy is a reminder that remote access must be designed as least privilege end to end. The control objective is not only to authenticate the user at the edge, but to ensure the resulting session cannot outlive the task or overreach the backend application. That means policy, revocation, monitoring, and cookie design must all be aligned before the proxy is considered safe for broader use.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 71% of NHIs are not rotated within recommended time frames, which helps explain why session and connector governance matter when access is brokered through proxy patterns.
• For a broader control model, see Ultimate Guide to NHIs , What are Non-Human Identities, which frames service accounts, tokens, and workload identities as governed assets.

What this signals

Proxy publishing will increasingly be judged by how well it constrains identity blast radius. The issue for practitioners is not whether remote access is possible, but whether each published application can be reviewed, revoked, and monitored with the same rigor as other NHI pathways. That pushes teams toward tighter application inventory, shorter session windows, and better connector scoping.

When 96% of organisations store secrets outside dedicated managers in vulnerable locations, as our research shows, any access path that depends on backend trust deserves extra scrutiny. Proxy-based access can be secure, but only when the surrounding identity hygiene is strong enough to support it. Otherwise, the proxy becomes another way to expose weak credential practices.

The practical signal is that IAM and NHI teams should fold application proxy settings into their access governance programme, especially where persistent cookies or long backend timeouts are enabled. That programme should be anchored in least privilege and aligned with the NIST SP 800-63 Digital Identity Guidelines where session assurance matters.

For practitioners

• Map proxy sessions to task scope Define which applications can tolerate persistent cookies and which must use short-lived sessions only. Tie the decision to business workflow, not convenience, and document the revocation path for each published app.
• Review connector permissions as NHI assets Inventory connector groups, isolate them per application where practical, and ensure each connector has only the network reach it needs. Treat connector host access as part of the NHI control set, not just server administration.
• Validate backend timeout settings against abuse windows Test whether long backend timeouts keep authenticated sessions alive longer than intended and whether stalled requests create an opportunity for misuse. Align timeout values with the sensitivity of the application and the expected transaction length.
• Harden cookie policy before broad remote access rollout Use HTTP-only and secure cookies by default, and reserve persistent cookies for tightly justified cases with compensating monitoring. If your app can function without persistent sessions, keep the exposure window short.
• Align proxy publishing with access review workflows Add published applications to user access reviews, and verify that the entitlement model reflects both the exposed application and the connector path. If you cannot review the access end to end, the proxy is carrying hidden standing access.

Key takeaways

• Azure AD Application Proxy reduces direct exposure, but it shifts security responsibility into the identity and session layer.
• Connector scope, cookie persistence, and backend timeout settings all change the real privilege boundary of the published application.
• Teams that manage proxy access as NHI governance will have a clearer path to least privilege, revocation, and auditability.

Key terms

• Application Proxy: An application proxy is a brokered access pattern that lets users reach internal applications through an external service instead of direct network exposure. In identity terms, it shifts trust into authentication, token handling, and connector reachability, which makes session management and revocation part of the security design.
• Connector Group: A connector group is a set of on-premises connectors that services published applications and forwards traffic to internal endpoints. It matters because connector placement defines the trust boundary, the failover model, and how much internal reach a remote access path can obtain if misconfigured.
• 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.
• Zero Standing Privilege: Zero Standing Privilege is an access model in which no credential or session is left active longer than necessary. For application proxy use cases, it means the published application should only remain reachable for the task at hand, with tight expiry, revocation, and review controls around the session path.

Deepen your knowledge

Azure AD Application Proxy governance and NHI session control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are assessing remote access patterns with similar identity and session risks, it is worth exploring.

This post draws on content published by Pathlock: Azure AD Application Proxy workflow and best practices. Read the original.