Here is a question that sorts access products into two groups, and it is not one most evaluations ask.
After the product has decided someone may connect — where is it?
Two architectures
In the first, the product evaluates the request at connection time. Identity is checked, policy is applied, a decision is reached, and a path is established between the user and the resource. The product then steps out of the way. Traffic flows.
In the second, the product terminates the session. It is one of the two parties in the connection — the user connects to it, and it connects to the resource. It remains in that position for the life of the session.
That is the difference between a broker and a reverse proxy. Both are real designs with real deployments behind them, and the distinction is not about which vendor is more capable.
But the consequences diverge more than the diagrams suggest.
What happens at the moment of connection
A product that brokers access from outside your identity environment can establish a path to almost anything. Most handle RDP and SSH perfectly well — carrying a protocol is not the hard part, and any claim to the contrary is wrong.
The hard part is what the application expects to receive when the user arrives.
An application that authenticates users itself — a modern web application speaking SAML or OIDC — needs nothing more than to be reachable. For that, brokering is entirely sufficient.
An application that expects its environment to have already established who the user is needs something else. It wants a Kerberos ticket obtained for that user, for that service. Or a header set by a component it trusts, positioned where it expects that component to be. Something has to produce that, and producing it requires being a participant in the transaction rather than an observer of its beginning.
This is why the awkward applications are awkward. Not the protocol. The identity.
What happens during the next four hours
The second divergence is larger and gets discussed less.
A product that stepped aside made one decision, at one moment, based on the state of things at that moment. Everything after that is outside its view. It can decline the next connection. It can do nothing about this one.
That matters in three distinct ways, and only the first is usually discussed.
The device stops being what it was
Posture at connection is not posture an hour later. The endpoint agent is stopped. A drive is attached. Something is installed. The machine that satisfied policy at 09:00 would fail it at 11:20, and nothing is asking.
The session reaches for things it was never granted
This one is larger. A decision at the front door authorizes access to something. It cannot verify that the session is subsequently used only for that.
If what is inside the session begins reaching for resources that were never part of the request — scanning, enumerating, following a path sideways — an architecture still in the line sees those attempts, because they have to pass through it. An architecture that stepped aside sees nothing, because that traffic never comes near it.
This is the difference between authorizing access and controlling it.
The attack begins after the connection
The most consequential case, and the hardest for a front-door model to address at all.
The credentials were valid. The device was compliant. The decision was correct. And then the session becomes the delivery vehicle for something that starts afterwards — a compromised endpoint, a stolen token replayed from elsewhere, a process acting through a session a human legitimately opened.
Every check happened before the thing that matters began.
In all three cases the original decision was right. That is what makes this a hard problem rather than a careless one: nothing was wrong at the moment of the decision, and nothing after that moment was examined.
Authentication is a moment. Access is a duration. Most access products are excellent at the moment.
And what ends up in the log
A third consequence, and the one that surfaces during audits.
If the enforcement point is only present at the start, its records describe admissions: who authenticated, when, from where, and whether the request was granted. That is an authentication log wearing an access log’s name.
Something in the path for the whole session can record what was actually reached. Those are different questions, and only one of them is the question an auditor asks.
Inline is a position, not a place
One clarification, because the language invites a misreading.
Being inline is about where a product sits in the transaction, not where it sits geographically. A reverse proxy can run in a datacentre, a private cloud or a public cloud. That is a deployment decision, driven by where the applications are and how the organization prefers to operate.
What matters architecturally is that it is in the line between the user and the resource, and that it operates within the identity environment of what it protects rather than brokering from outside it. Both of those are true wherever it happens to run.
“Cloud-delivered” and “brokered from outside” are frequently the same thing in practice, but they are not the same claim, and it is worth keeping them apart when comparing products.
Why this decides which half of your estate you can cover
These two consequences are not independent of the coverage question. They are the reason for it.
The applications that resist migration to a modern platform are the ones that expect identity presented in a particular form. That is the connection-time consequence. And they are frequently the applications where a point-in-time decision is least adequate — administrative access, industrial systems, anything where a session running for hours does more than read a page.
So a product that is not in the path is not merely less thorough. It is structurally unable to reach part of the estate, and the part it cannot reach is disproportionately the part that matters.
The question to ask any vendor
Not “do you support RDP”. Everyone supports RDP.
Ask instead: two hours into a session your product authorized, where is your product? If the device has stopped being compliant, what happens? And if something inside that session starts reaching for resources it was never granted, which component sees the attempt?
Ask us the same question. The answer should be specific, and if a product cannot do something, that is far better learned in a conversation than in a pilot.