Identity-Aware Proxy: Why Legacy Applications Should Never Face the Internet Directly

Last reviewed: July 23, 2026. The CVE examples below were checked against public vendor and CISA guidance on that date.

What is an identity-aware proxy?

An identity-aware proxy is a reverse proxy that authenticates every request against an identity provider such as Microsoft Entra ID or Okta, then enforces MFA and access policy before traffic is forwarded to the application behind it. The application itself is never directly reachable from the internet. Anonymous traffic does not get a login page, an error page, or an API endpoint; it gets stopped at a layer whose job is deciding identity.

The pattern has a respectable lineage. Google Cloud still describes Identity-Aware Proxy as a way to control access to applications by verifying identity and request context. The principle that matters here is simple: trust should be established per request, based on identity, not merely by network location. A packet arriving at your application should already carry a verified answer to “who is this?” instead of making the application discover that answer itself.

That principle was written for modern applications. It matters even more for legacy ones: PeopleSoft, Oracle E-Business Suite, JD Edwards, on-premises SharePoint, and other systems that were not designed for today’s internet-exposed threat model. The recent exploitation record makes the case better than any architecture diagram could.

The pattern: what exploited SharePoint and ERP CVEs have in common

Recent CISA KEV entries and vendor advisories show the same architectural pattern repeating across collaboration, HR, payroll, and ERP systems.

In July 2025, the ToolShell campaign chained SharePoint Server flaws including CVE-2025-53770 into unauthenticated remote code execution, with attackers stealing ASP.NET machine keys to forge authentication material. That persistence survived patching, which is why Microsoft’s remediation guidance included key rotation, not just updates.

In mid-2026, the pattern moved through ERP systems as well. PeopleSoft and Oracle E-Business Suite vulnerabilities created urgent remediation pressure for systems holding HR, payroll, and payments data. Internet exposure turned quiet architecture decisions into incident prerequisites.

Then came another SharePoint run: multiple SharePoint Server vulnerabilities under active exploitation, culminating in CVE-2026-50522. We covered the deeper remediation checklist in our CVE-2026-50522 post.

Different vendors. Different bug classes. But strip away the CVE numbers and the same precondition remains: a complex application server whose endpoints were directly reachable by anonymous internet traffic. The exploit request did not need a valid session. It did not need to pass MFA. It did not need to be anyone. It just needed to reach the server.

The patch race is now measured in hours

The traditional answer to this problem is patch cadence: subscribe to advisories, patch fast, and stay ahead. That answer assumed a grace period between disclosure and weaponization measured in weeks.

That grace period is shrinking. Public proof-of-concept code, automated scanning, and opportunistic exploitation often arrive before enterprise change windows can move. Meanwhile, production ERP and SharePoint deployments still require change control, integration testing, and scheduled downtime for good operational reasons. An organization that patches a production PeopleSoft or SharePoint environment within two weeks of a critical advisory may be performing well, but two weeks can still be a long exposure window.

This is why compensating controls for unpatched vulnerabilities have moved from audit-checklist vocabulary to operational necessity. A compensating control does not replace the patch. The patch closes the vulnerability. The compensating control changes what the exposure window means. If the only traffic that can reach your application during that window is authenticated, MFA-verified, and attributable to a named identity, then a pre-auth remote code execution flaw has no anonymous path to the server.

Zero trust for legacy applications: shrink the surface, do not just move it

Putting an identity-aware proxy in front of SharePoint or PeopleSoft does not make the attack surface disappear. The internet now talks to the proxy. The real claim is more precise: the thing facing the internet should be a small, purpose-built authentication layer whose job is deciding identity, not a sprawling application platform whose authentication code is one feature among thousands.

That asymmetry is what makes this useful zero trust identity security rather than security theater.

• Parsing surface. SharePoint, ERP, and legacy web platforms expose years of compatibility paths, service endpoints, and framework behavior. A hardened access proxy exposes a smaller parsing surface because it does one job.
• What happens on rejection. When the proxy rejects an unauthenticated request, the exploit payload is never parsed or evaluated by the application behind it.
• Blast radius of a proxy bug. No software is invulnerable, including proxies. But a flaw in a stateless authentication layer is a different operational problem than a flaw in the system holding payroll data, documents, payments workflows, and application secrets.
• Identity as the perimeter. Once every request carries a verified identity, the controls your legacy application never had become available to it: MFA, conditional access, and logs that name identities rather than anonymous IP addresses.

Is a VPN enough to protect internal applications?

No, not by itself. A VPN authenticates once at the network edge and then extends network-level trust to everything reachable inside. That model fails the current threat environment in three ways: a single compromised credential or vulnerable VPN appliance grants a foothold beyond one app; there is no per-application MFA or policy; and lateral movement becomes the attacker’s problem to solve, not yours to prevent.

An identity-aware proxy inverts the pattern: authentication happens per request, per application, with policy evaluated each time. The two can coexist. A proxy behind a VPN can be defense in depth. But a VPN alone answers “are you on the network?” when the better question is “who are you, and should you reach this application right now?”

Identity-aware proxy vs. WAF and virtual patching

Web application firewalls approach the problem from another direction: they forward traffic but inspect it, matching requests against known attack signatures. That can be valuable, especially for attacks arriving through authenticated sessions.

The distinction is precise. A WAF asks “does this request look malicious?” and must keep answering correctly as exploits mutate. An identity gate asks “is this request from a verified identity?” That question does not depend on recognizing a brand-new payload. The honest ordering is identity gate first to remove the anonymous path, with WAF as depth behind it.

Identity-aware proxy vs. ZTNA

Zero Trust Network Access products solve an overlapping problem: brokering workforce access to private applications, often through a vendor cloud and often with an endpoint agent. For remote workforce access to internal apps, ZTNA can be a legitimate and mature pattern.

The identity-aware proxy pattern differs in where the enforcement point lives and who it serves. The proxy sits with the application, works for users who cannot run your endpoint agent, and keeps applications reachable at their own addresses for workflows that require it. That matters for partners, contractors, customers, ERP self-service users, and regulated environments where traffic placement and application ownership matter.

What this pattern honestly does not do

We build identity infrastructure, so we should state the limits as plainly as the capabilities.

• It does not replace patching. The proxy shrinks the exposure window; the patch closes the hole. Both matter.
• It does not undo a compromise that already happened. If machine keys, secrets, sessions, or credentials were stolen before the control existed, rotation and incident response are still required.
• It does not stop an attacker holding valid, MFA-passing credentials. It removes the anonymous path, but a fully compromised identity can pass an identity gate. Conditional access, session controls, and monitoring still matter.
• It only works if it is the only door. Application servers must be firewalled to accept traffic solely from the proxy. A proxy in front of a still-directly-reachable server is not enough.

How Datawiza applies this to SharePoint, PeopleSoft, Oracle EBS, and JDE

The Datawiza Access Proxy is an identity-aware proxy purpose-built for legacy and on-premises web applications. It deploys in front of the application with no code changes, authenticates every request against your existing identity provider such as Microsoft Entra ID, Okta, or others, or provides built-in MFA where no IdP integration exists, and forwards only verified traffic to the application.

The integration depth is application-specific and documented: PeopleSoft SSO/MFA, Oracle E-Business Suite, JD Edwards, and a SharePoint on-premises Entra ID SSO and MFA integration guide. The same access-layer pattern can also work with other identity providers such as Okta, Ping, Cisco Duo, Google Identity, and others depending on the deployment.

If the past year’s exploited-vulnerability record has you rethinking what your ERP and SharePoint servers are exposed to, that is the right instinct. Book a 30-minute demo and we will show you what the identity-aware proxy pattern looks like in front of your specific applications.

FAQ

What is an identity-aware proxy?

An identity-aware proxy is a reverse proxy that authenticates every request against an identity provider such as Microsoft Entra ID or Okta and enforces MFA and access policy before traffic reaches the application. The application is not directly reachable from the internet; only verified, attributable requests are forwarded.

Should SharePoint be exposed to the internet?

On-premises SharePoint should not be directly reachable by anonymous internet traffic. Multiple SharePoint Server vulnerabilities were actively exploited in 2025 and 2026 through unauthenticated requests, including scenarios involving machine-key theft. If remote access is required, place an identity-aware proxy with MFA in front and firewall the servers to accept only proxy traffic.

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

Patch promptly, then remove the anonymous path. Put an identity-aware proxy in front so every request must authenticate against your IdP and pass MFA before reaching the application, and firewall application servers to accept traffic only from the proxy. Add monitoring and a WAF as additional depth.

Is a VPN enough to protect internal applications?

No. A VPN authenticates once at the network edge and then extends network-wide trust, enabling lateral movement and offering no per-application MFA or policy. An identity-aware proxy authenticates every request per application. The two can be layered, but a VPN alone does not provide zero trust application access.

How do you add MFA to internet-facing applications?

The fastest path for applications without modern authentication support is an identity-aware proxy. It enforces MFA at the proxy layer using your existing provider such as Entra ID or Okta, or built-in MFA when you do not want a new IdP project, with no application code changes. Legacy platforms like PeopleSoft, Oracle EBS, JD Edwards, and on-premises SharePoint can gain MFA and conditional access this way.