Every enterprise has applications that were built before zero trust existed. Here is why modern identity platforms cannot protect them — and what to do about it.
Zero trust is the right architecture. The principles are sound. The frameworks — NIST 800-207, CISA guidance, OMB M-22-09 — are well-constructed. And yet, enterprise after enterprise finds itself in the same uncomfortable position: a partially-implemented zero trust programme that protects cloud-native SaaS applications beautifully while leaving the most critical systems in the organisation completely exposed.
The problem is not the strategy. The problem is the assumption embedded in almost every zero trust product on the market.
The Hidden Assumption
Modern identity platforms — Okta, Microsoft Entra, Google Identity — are built on a simple premise: applications speak modern protocols. SAML 2.0. OIDC. OAuth 2.0. If your application supports one of these, you can integrate it. If it does not, you cannot.
This premise is never stated explicitly. It is baked into product documentation, integration guides, and pricing pages. But its consequences are enormous. Consider what it excludes:
- Thick-client applications — desktop software that opens a direct TCP connection to a backend server. No browser. No redirect. No SAML assertion.
- Forms-based login screens — the HTML username/password form that has powered enterprise applications since 1997. Cannot be federated without modifying the application.
- Kerberos-authenticated systems — legacy Windows applications that rely on Kerberos tickets, not tokens.
- IoT management consoles — the web interface for your building management system, industrial controller, or network device.
- Custom internal tools — the internal HR portal built in 2008, the ticket system that runs operations, the financial reporting tool that finance refuses to replace.
These are not edge cases. In most enterprises, these applications represent a significant fraction of the access control surface — and frequently the most sensitive fraction.
The Gap in Practice
What happens in practice is this: an organisation deploys a modern identity platform, completes the integrations for all their cloud applications, and declares their zero trust programme a success. The dashboard shows 847 applications protected. The auditors are satisfied.
Meanwhile, the thick-client ERP that processes every financial transaction is protected by a username and password from 2011 that has never been changed. The IoT management console for the HVAC system is accessible from the internet on port 8080. The forms-based HR portal has no MFA because there was nowhere to plug it in.
The zero trust programme is real. The gap is also real. And attackers are very good at finding gaps.
Why “Refactor the Application” Is Not an Answer
The vendor answer to this problem is usually “refactor the application to support modern protocols.” This is technically correct and operationally absurd.
The thick-client ERP system has seven million lines of code written across fifteen years by teams who no longer work at the company. Refactoring it to support OIDC would cost more than the company paid for it originally — if it is even possible. The HIPAA-covered patient records system cannot be touched without going through a change management process that takes eighteen months and costs half a million dollars in validation.
“Refactor the application” is the answer that vendors give when they have not solved the problem.
The Reverse Proxy Approach
The correct architectural answer is not to change the application. It is to intercept access to the application.
A reverse proxy sits between users and applications at the network layer. Every request to a protected application passes through the proxy — which can enforce authentication, MFA, device posture, and continuous validation regardless of what protocols the application understands. The application never sees an unauthenticated request. It does not need to know about SAML or OIDC.
This is how Total Access Control (TAC) approaches the problem. TAC’s reverse proxy injects MFA, device posture checks, and continuous validation in front of any application — thick-client, forms-based, Kerberos, IoT, anything — without requiring a single line of application code to change.
The results are concrete. A legacy EHR system that cannot support SAML gets FIDO2 phishing-resistant authentication. A thick-client financial tool gets device posture checks on every session. An IoT management console gets SSO through the same portal as every other application. None of these applications were modified.
What This Means for Your Zero Trust Programme
A zero trust programme that protects only modern applications is not a zero trust programme. It is a partial defence with a known gap that every attacker can identify.
Before selecting zero trust tooling, ask one question: what happens to my applications that cannot support SAML or OIDC? If the answer is “we would need to refactor them” or “those would stay on VPN,” you have found your gap.
PortSys builds Total Access Control — a unified zero trust platform that protects every application, including the ones modern identity providers cannot reach. Learn how TAC works →