What Is an Identity-Aware Proxy? Secure Access for Web Apps

Technical accuracy reviewed September 2026. Vulnerability examples below are dated; consult current vendor guidance for affected versions and remediation.

What is an identity-aware proxy?

An identity-aware proxy is a reverse proxy that uses verified identity and available request context to enforce access policy before forwarding protected web requests to an application. It checks an existing session or token and initiates authentication or MFA when required. It does not necessarily contact an identity provider or prompt for MFA on every request.

For this to protect an application's login page or other pre-login endpoints, the access check must happen before those endpoints receive the request. Network controls must also prevent direct access that bypasses the proxy. An intentionally public route is outside that identity gate's protection.

For example, Google Cloud IAP documents session cookies and authorization checks. Its session behavior is product-specific, but the distinction is useful: checking access on a request is not the same as repeating the user's login. Reauthentication, expiration, and revocation behavior depend on the implementation and configuration.

This approach can support custom applications, customer and partner portals, internal tools, and older platforms such as PeopleSoft, Oracle E-Business Suite, JD Edwards, and SharePoint. Compatibility depends on the application's protocols, authentication flow, and deployment—not simply its age.

What exploited SharePoint and ERP vulnerabilities illustrate

Dated vendor reports and CISA records show why exposed application endpoints deserve attention. Their exploit prerequisites differ, so protections must be evaluated against the affected functionality.

In July 2025, Microsoft documented active SharePoint attacks involving the ToolShell vulnerabilities, including CVE-2025-53770. Observed attacks retrieved ASP.NET machine-key material. Microsoft's response included security updates, key rotation, restarting IIS, and incident-response investigation—not patch installation alone. This guidance concerned on-premises SharePoint, not SharePoint Online.

Oracle's June 10, 2026 PeopleTools advisory addressed unauthenticated compromise through CVE-2026-35273. Its May 2026 update also addressed CVE-2026-46817 in the Oracle Payments component of E-Business Suite. These are specific vulnerabilities, not claims that every ERP installation is affected.

CISA's Known Exploited Vulnerabilities data records PeopleTools CVE-2026-35273 on June 12, Oracle EBS CVE-2026-46817 on July 15, and SharePoint CVE-2026-50522 on July 22, 2026. Catalog addition dates are not necessarily the first exploitation dates.

An identity-aware proxy can reduce an unauthenticated route to exploitation only when it enforces access before the affected endpoint and cannot be bypassed. These examples do not establish that a proxy detects those vulnerabilities or stops every exploit.

Why access controls matter while teams patch

Patch promptly, but also control exposure during remediation. The UK NCSC assesses that AI will improve vulnerability research and exploit development. That adds pressure without creating a universal timeline between disclosure and attack.

Production updates can require compatibility testing, application-owner approval, and a recovery plan. During that work, teams may restrict affected routes to essential users or temporarily deny unnecessary functionality. If the remaining risk is unacceptable, follow vendor guidance on isolation or service suspension rather than assuming an access proxy makes delay safe.

These are risk-reduction measures, not substitutes for remediation. A proxy may help buy time by reducing reachable attack paths, but it cannot guarantee a safe patching window. See how to protect unpatched web applications while you patch.

Zero trust application access: validate the boundary

An identity-aware proxy adds an enforcement point; it does not make the application or proxy invulnerable. NIST's zero trust architecture separates authentication from authorization and rejects implicit trust based only on network location.

Translate that principle into testable deployment requirements:

• Prevent bypass. Restrict protected origins so requests cannot avoid enforcement through direct IPs, alternate hostnames, ports, or internal routes. DNS changes alone are insufficient. Inventory intentional public exceptions separately.
• Choose the enforcement point. To protect an application's login endpoint, enforce authentication and authorization before that endpoint receives the request. MFA after application login protects a different boundary.
• Maintain the proxy. Patch, harden, and monitor it, protect its configuration and secrets, and plan availability. A proxy flaw can still have serious consequences; do not assume a smaller blast radius.
• Test sessions and policy. Validate expiration, logout, reauthentication, disabled-user access, and deny rules. Device posture and risk signals depend on the integration; immediate revocation is not universal.

For a practical framework covering identity verification, least-privilege access, and ongoing evaluation, see our zero trust application security guide.

Is a VPN enough to protect internal applications?

A VPN can reduce public exposure and support MFA, segmentation, and access restrictions. For example, Azure VPN Gateway supports Entra ID MFA and Conditional Access. It is inaccurate to assume every VPN grants unrestricted network access or lacks MFA.

The decision is where to enforce access for each application. An identity-aware proxy can add application/path-level controls to a VPN-protected environment, or provide a browser-based access path for compatible apps. Review the remaining protocols and workflows before treating it as a complete VPN replacement.

Identity-aware proxy vs. WAF and virtual patching

A WAF inspects web traffic and can allow, block, rate-limit, or challenge requests according to its rules. It is not limited to forwarding traffic or matching known exploit signatures; AWS WAF documents several inspection criteria and actions.

An identity-aware proxy focuses on who may reach protected resources. WAF or IPS virtual patching targets exploit attempts; software patching fixes the underlying code. These controls can complement one another. Their order depends on the deployment: protect the proxy as well as the application, and avoid paths that bypass the intended checks.

Identity-aware proxy vs. ZTNA

ZTNA and identity-aware proxy capabilities overlap. An identity-aware proxy can be part of a ZTNA architecture; the labels are not mutually exclusive. Vendors differ in supported protocols, endpoint requirements, deployment locations, policy depth, and session behavior.

Datawiza Access Proxy can run in your environment and support browser-based access to compatible web applications. This can serve workforce users, partners, contractors, and customers, including broader private-access projects. Evaluate the actual application portfolio and operational requirements rather than assuming every IAP or ZTNA product works the same way.

What this pattern honestly does not do

Access-layer enforcement has important limits:

• It does not replace patching. Reducing unauthenticated exposure does not repair vulnerable code or justify missing remediation deadlines.
• It does not undo a compromise. Stolen keys, secrets, credentials, or sessions may still require rotation, investigation, and recovery.
• It does not make permitted traffic harmless. An authorized attacker or compromised session may reach vulnerable functionality. Public exceptions, server-side attack paths, and proxy vulnerabilities need separate attention.
• It does not replace application permissions. A path-level rule cannot establish which customer records a user may access. Keep object-level authorization and business-logic checks in the application.

How Datawiza adds MFA and access policies to web apps

Datawiza Access Proxy adds authentication and granular access policies to compatible HTTP/HTTPS applications without requiring each application to implement MFA. It can run on-premises or in the cloud, with centralized configuration through the Datawiza Cloud Management Console. Choose the identity approach that fits your users:

• Built-in MFA with existing application credentials. An external identity provider, Active Directory, or LDAP is not required. Datawiza supports pre-login MFA when enforcement is needed before the application's login page. Retaining application accounts does not automatically create SSO across unrelated apps. See MFA with existing application credentials.
• Existing identity provider. Connect supported providers such as Microsoft Entra ID, Okta, or Cisco Duo for SSO/MFA and access policies. Available groups, roles, device signals, and risk information depend on the provider and configured integration.

Datawiza's granular access rules can use paths, HTTP methods, and available identity or request attributes. Configure rule priority and the default action deliberately. Application-specific examples include PeopleSoft, Oracle E-Business Suite, JD Edwards, and SharePoint.

No-code MFA does not mean zero configuration. Review routing, certificates, public exceptions, and bypass prevention. SSO, trusted-header, and logout integration may require application-specific settings or changes; Datawiza's custom-app guide illustrates this. Test application and proxy sessions together, including any APIs or long-lived connections.

Book a 30-minute demo to review your applications, authentication flows, access policies, and deployment requirements with Datawiza.

FAQ

What is an identity-aware proxy?

It is a reverse proxy that evaluates verified identity and applicable access policy before forwarding protected web requests. It can validate sessions or tokens without repeating login or contacting the identity provider on every request. Direct-origin access must be restricted separately.

Should SharePoint be exposed to the internet?

Do not leave protected SharePoint endpoints reachable through a route that bypasses your access controls. Restrict access appropriately and follow Microsoft's current patching, hardening, and incident-response guidance. An access proxy does not replace those measures.

How do you protect on-prem applications from the internet?

Combine prompt patching with authentication, least-privilege access, direct-origin restrictions, and monitoring. An identity-aware proxy can enforce access before protected web endpoints; other protocols and intentionally public routes require their own controls. Test the full request path.

Is a VPN enough to protect internal applications?

It depends on its configuration and the application's requirements. VPNs can provide MFA and restricted access, but network connectivity alone does not establish application authorization. An identity-aware proxy can complement a VPN with application/path-level enforcement.

How do you add MFA to internet-facing applications?

For compatible web apps, Datawiza offers built-in MFA without AD, LDAP, or an external IdP, or integration with an existing provider for SSO/MFA. Users can retain existing application credentials in built-in mode. Validate enrollment, recovery, identity mapping, session behavior, and the placement of MFA before rollout.

Related guides

If you are evaluating this pattern for third-party access, see a VPN alternative for contractors and third parties. If you are exposing private web apps more broadly, see how to publish on-premises web applications securely.