Unpatched Vulnerabilities in the AI Era: Protect Web Apps While You Patch
Table of contents
Unpatched vulnerabilities are security weaknesses that remain unresolved in the software you run. Some have fixes that have not yet been deployed; others are still awaiting a vendor fix. For web applications, the immediate concern is who can reach the affected code.
A new vulnerability is disclosed. Your team needs to identify affected applications, test the update, coordinate with application owners, and deploy it. Attackers do not have to wait for that process to finish.
AI adds urgency. The UK's National Cyber Security Centre assesses that AI will strengthen vulnerability research and exploit development. In May 2026, it also urged organizations to prepare for a wave of security patches and reduce their externally exposed attack surfaces. NCSC AI threat assessment; NCSC patch-wave guidance.
For IT teams, the practical question is not just, “How quickly can we patch?” It is also, “Who can reach the vulnerable application while we patch?”
An identity-aware proxy can help protect unpatched web applications by restricting access before requests reach protected application endpoints. Datawiza Access Proxy supports this approach with pre-login MFA, identity-based access policies, and no-code application integration.
The goal is to reduce exposure during remediation—not to replace remediation.
1. Make vulnerable endpoints harder to reach
An application can require a password and still expose vulnerable code to anonymous visitors. Its login page, administrative endpoints, or other publicly reachable routes may process requests before the application authenticates anyone.
An identity-aware proxy introduces an independent access check in front of the application. When configured to enforce authentication and authorization before forwarding protected requests, it can reject unauthorized visitors without sending those requests to the protected endpoint.
This applies a zero trust principle: network location alone does not justify access. NIST describes resource-focused access decisions with authentication and authorization before a session is established. An identity-aware proxy contributes to that architecture; it is not a complete zero trust program by itself. NIST Zero Trust Architecture.
Consider an unauthenticated remote code execution vulnerability in a web application. If exploitation requires reaching a particular endpoint, a correctly enforced pre-authentication gate can remove that anonymous route to exploitation. This is an architectural benefit—not a claim that the proxy recognizes or fixes the vulnerability.
Two conditions are essential:
- Enforce the gate before the affected endpoint receives the request. Showing an MFA prompt after application login is not equivalent to protecting the login endpoint itself.
- Prevent direct-origin access. Network controls must stop users from bypassing the proxy through the application's IP address, alternate hostname, port, or another reachable interface. Changing DNS alone does not accomplish this.
The application may remain discoverable, and the proxy remains an exposed component. The benefit is controlled access to protected application routes, not invisibility or immunity from attack. See our identity-aware proxy guide for the underlying architecture.
2. Reduce risk while patches are tested and deployed
Patching a business-critical application can require vendor coordination, compatibility testing, approval, and a recovery plan. That work still needs to happen.
An already-deployed access layer gives security teams another response option while remediation proceeds. Depending on the affected functionality, they can narrow access to essential users, restrict an administrative route, or temporarily deny access to a feature that is not required for current operations.
This is how an identity-aware proxy can help buy time to patch: by reducing reachable attack paths during the patch window. It does not create a guaranteed safe delay or justify extending patch deadlines automatically.
Treat temporary restrictions as documented risk mitigations with an owner, validation results, and an expiration or review date. If the remaining risk is unacceptable—or vendor guidance requires it—disable the affected service until it can be secured.
3. Gain more than a temporary patching measure
The same access layer can provide lasting benefits after the patch is installed.
Apply consistent controls across applications
Use a common approach for custom applications, packaged software, ERP systems, internal tools, and customer or partner portals. Security does not have to depend entirely on each application's native authentication features.
Change access without waiting for an application release
Datawiza supports centrally managed rules using application paths, HTTP methods, and available identity or request attributes. Teams can adjust access independently of the application's development cycle. The attributes available depend on the authentication integration. Datawiza granular access control.
Limit unnecessary access between applications
Being able to use one application should not automatically grant access to every other application. Separate policies can reduce unnecessary access across a web-app portfolio. Combine them with network segmentation and application permissions; proxy rules alone do not contain every consequence of a compromised server.
Improve visibility during incident response
Authentication and access logs can help teams understand which identities attempted access and which policies applied. Combine those records with application, WAF, endpoint, and infrastructure logs. A permitted request is not proof that its contents were harmless, and a lack of alerts is not proof that no compromise occurred.
How Datawiza Access Proxy fits
Datawiza Access Proxy adds an authentication and access-policy layer to HTTP/HTTPS applications without changing their code. The proxy can run in your environment, with centralized cloud management.
Choose the authentication model that fits your users:
- Keep application credentials and use Datawiza built-in MFA. Configure the supported pre-login MFA mode when the objective is to gate access before application login. Users can retain their application credentials without introducing Active Directory, LDAP, or an external identity provider.
- Connect an existing identity provider. Use supported providers such as Microsoft Entra ID, Okta, or Cisco Duo for SSO/MFA, with access policies appropriate to the application and available identity attributes.
For either model, verify where enforcement occurs. Review login routes, recovery pages, APIs, callbacks, and every configured exception. MFA confirms an authentication factor; authorization must also determine which users may reach each protected resource. Built-in MFA does not automatically create SSO across unrelated application accounts.
This approach is not limited to legacy applications. It can support a broader private-access project across compatible web applications and hosting environments.
Identity-aware access is not the same as virtual patching
These controls solve related but different problems:
- Identity-aware access determines who may reach a protected application or route.
- WAF or IPS virtual patching uses validated rules to intercept attempts to exploit particular vulnerabilities.
- Software patching corrects the underlying vulnerable software.
OWASP describes virtual patching as an enforcement mechanism that intercepts exploitation attempts without modifying the application's source code. Do not assume that an authentication proxy performs that vulnerability-specific inspection. The controls can complement one another. OWASP virtual patching guidance.
An authorized attacker or someone using a compromised session may still reach vulnerable functionality. Routes that must remain publicly accessible need other protections. Server-side attack paths and vulnerabilities in the proxy itself also require attention. Maintain the proxy and identity infrastructure as carefully as the applications they protect.
A practical checklist for the next vulnerability advisory
- Confirm impact. Identify affected versions, exposed endpoints, business impact, and evidence of exploitation. A CVE identifier names a vulnerability; it does not by itself establish active exploitation. Use vendor advisories and CISA's Known Exploited Vulnerabilities catalog to inform prioritization.
- Map every access path. Include public addresses, internal routes, alternate ports, and interfaces outside the proxy's protection.
- Validate the gate. Confirm that unauthenticated and unauthorized requests cannot reach the affected protected endpoint. Test exceptions and direct-origin restrictions.
- Reduce access where useful. Restrict affected routes or users while preserving only the access your risk assessment permits.
- Patch and verify. Apply the fix promptly, check for compromise when warranted, and confirm remediation. Review temporary rules without removing useful least-privilege controls.
Make application exposure part of your patching plan
AI does not change the need to patch. It makes relying on patch speed alone a less comfortable strategy.
Datawiza Access Proxy can add another layer: verify users, enforce application access policies, and reduce unnecessary exposure while your team completes remediation.
Book a demo to evaluate pre-login MFA, identity-provider integration, and access restrictions for your web applications.
