Last September we wrote about why modern access platforms cannot front certain applications — the ones that expect a Kerberos ticket, the thick clients, the forms-based systems, the consoles and custom tools that never learned to speak SAML or OIDC. That post was about the technical boundary.
This one is about something more mundane and, in practice, more expensive. Almost nobody has written down which of their applications are on the wrong side of it.
Everyone knows. Nobody owns the set.
Ask any individual engineer about any individual application and you will get a precise answer. The knowledge exists. What does not exist is the set.
The reason is structural rather than careless. Each of these applications became an exception inside a different project — a migration, a platform rollout, an acquisition integration, a compliance remediation. Each exception was documented where that project documented things, approved by whoever was accountable at the time, and given a review date. Then the project closed. The people moved. The documents went wherever closed project documents go.
The exceptions persisted. The record of them dispersed. And because no single program ever owned the whole set, no single program was ever asked to produce it.
What it costs to not have the list
Three consequences, and the third is the one that keeps the situation stable for years.
You cannot scope an evaluation
Every access product will tell you it supports RDP and SSH, and most of them genuinely do. The discriminating question is not about protocols — it is whether a product can front the specific applications you have. Without the list you cannot ask that question, so you evaluate on features instead, and discover the gap during a pilot.
You cannot describe the risk
“Some older applications are still on the VPN” is not a statement anyone can act on. A page naming eleven systems, four of which hold regulated data and two of which are reachable by third parties, is a different kind of document entirely — and it is the same information, just assembled.
You cannot cost it, so it never competes
This is the important one.
Budget goes to problems with numbers attached. A problem that exists as scattered exceptions in closed project documentation has no number, cannot be put on a slide, and therefore never appears on the list of things being funded this year.
So it remains a running expense and a standing exposure that no business case has ever had to justify — not because anyone decided it was acceptable, but because nobody has ever been in a position to ask for the money. The cost is real and it is being paid. It is simply being paid invisibly, which is the only condition under which a cost survives indefinitely.
Write the list
One page. For each application that did not move, four columns:
- What it expects at the point of authentication — a Kerberos ticket, a header set by a trusted component, a local account, nothing at all.
- Who needs to reach it, and from where. Staff, administrators, third parties, equipment.
- What access path they use today — and what else that path also grants them.
- What keeps it where it is. Technical constraint, vendor support agreement, or simply that nobody has had the time.
The fourth column is the one that surprises people. A meaningful share of any such list turns out to be the third answer — no technical obstacle at all, just an item that has never been anyone’s priority. Those are free wins sitting in plain sight, and they are invisible until the list exists.
The third column is the one that changes the conversation. It is where somebody notices that the path serving four legacy applications also grants a route to everything else on that network segment.
What the list is actually for
With it in hand, the evaluation question changes shape. It stops being “which platform is best” and becomes “which of these could front every line on this page”.
That is a far more discriminating question, it can be asked of any vendor in a first conversation rather than discovered in month three of a pilot, and it is the question Total Access Control was built to answer — an enforcement point that presents identity in the form each of these applications expects, rather than one that can only route a connection to them.
But the list comes first, and it is worth producing whatever you conclude afterwards. The organizations that handle this well are not the ones with the best platform. They are the ones who know what is on the page.
Most have never seen it on one. The reaction when they do is consistent: shorter than feared, and more important than expected.