You bought a modern access platform. It was deployed. It works. People are pleased with it.

And the VPN is still running.

What it is still there for

Ask which applications still require it and a list appears. It is never a long list, and it is never written down anywhere in full.

Thick clients. Something that expects a Kerberos ticket. An OT segment where the device initiates the session. A system a vendor supports on the condition that nothing about it changes. Possibly an acquisition that was never properly integrated and now never will be.

That list is the hard half of your estate. The new platform covered what it could cover, which was the applications that were easiest to cover — and that was a reasonable place to start, because it delivered value quickly and demonstrated the model worked.

Nobody did anything wrong. But the project that was supposed to retire the VPN did not retire the VPN.

So you added. You did not replace.

This is the point at which it stops being a procurement footnote and becomes an architecture problem.

You now run two access paths in parallel where you meant to run one. That is another internet-facing doorway on top of whatever was already exposed — another management plane, another set of credentials, another vulnerability stream, another thing to patch when an advisory lands on a Friday afternoon.

And it is worth being honest about the count. It is rarely two. Alongside the VPN and the new platform there are usually applications published directly to the internet, a remote-access route somebody set up for a supplier, an administrative interface that was only ever meant to be temporary. Every one of them is a doorway that has to be defended.

Both serve the same estate. Neither covers all of it.

The attack surface did not shrink. It grew — as the direct result of a project justified in part on shrinking it.

The business case nobody restated

Somewhere there is a paper that made the case for the new platform, and somewhere in that paper is an assumption that the VPN would be retired. License savings, perhaps. Reduced operational burden. One fewer thing exposed.

Nobody went back and revised it once the assumption turned out to be false.

That is not dishonesty. Nobody ever goes back. Projects are judged on whether they delivered what they said, and this one did — it just also left something behind that the case had assumed would go away.

The consequence is that the cost of the hard half has never actually been counted. It sits in the estate as a running expense and a standing exposure that no business case has ever had to justify.

And now the VPN is neglected as well as exposed

This is the part that should be uncomfortable.

Once a system is designated legacy and scheduled for removal, it stops attracting investment. The version upgrade is deferred — why upgrade something being retired next year. Access reviews slip, because the population using it is small and shrinking. Dormant accounts linger. The firmware is a version behind, then two. The engineer who understood it best moved to the team running the new platform.

Meanwhile it remains an internet-facing route onto your network.

A deprioritized front door is more dangerous than a maintained one. So the position is not simply that you failed to remove the VPN. It is that the VPN you still have is less well looked after than the VPN you had before the project started.

Why it is still there is the actual problem

The VPN persists for one reason: nothing available could front the awkward applications, so the old path had to stay for them.

That reason does not change by buying another platform with the same boundary. A second modern product, brokering access from outside your directory in the same way, produces the same outcome — another layer, another front door, and the same list left over at the end.

The list is the problem. Everything else is a symptom of the list.

What actually removes it

An enforcement point that can front the hard half.

Total Access Control terminates the session in front of the application, inside your environment — and it does that for the whole estate, not for a category of it. The SaaS and cloud applications your current platform already handles well, the internal web applications, and the ones that would not move.

Because it is inline — in the path of the transaction rather than alongside it, and operating within your identity environment rather than brokering from outside it — it can present the identity an application actually expects: a Kerberos ticket, an injected header, a session into an OT segment where the device initiates the connection. The awkward applications stop being awkward, because the thing in front of them speaks their language.

Where it runs is a separate question and a free one. Datacentre, private cloud, public cloud — that is a deployment decision to suit the estate. What matters architecturally is that it sits in the line between the user and the resource, for the whole session, rather than issuing a decision at the front door and stepping aside.

That distinction is the point. Something that fronted only the difficult applications would leave you with two platforms instead of one — which is the position you are already in, with better branding.

It goes in beside the VPN, not instead of it. One population moves — usually third parties or remote administrators, the group with the most risk and the least tolerance for a laptop rollout. Both paths run side by side. The next group moves once the first has become boring.

The VPN shrinks until it has nothing left to serve. At that point removing it is an administrative task rather than a project, which is the only way these things ever actually get removed.

Some estates keep one for a single purpose indefinitely, and that is a perfectly good outcome — provided it is a decision someone made rather than a residue nobody got around to clearing.

And the next one is already being sold to you

AI agents are arriving in production estates now. They act on behalf of people, they hold credentials, and they make requests against the same applications your staff use. A category of products is forming to govern them.

When one is put in front of you, the questions worth asking are the ones nobody asked about the platform that was supposed to reduce the number of doorways and instead added one:

• Does this make my life easier, or does it add another console to watch?
• Does it give me more control over access, or does it move some of that control somewhere else?
• Will people and agents be governed in one place, or in two?
• When this is deployed, what is left over — and who owns it?

None of those questions are about AI. They are the questions that should have been asked about the last platform, and the one before that.

The pattern is not the VPN. It is the assumption that covering part of the estate counts as progress.

So: why do you still have a VPN?

If the answer is a list of applications, that list is your architecture problem.

It is the thing to solve — not the VPN, and not with another platform that cannot reach the things keeping the VPN alive.

How many separate products currently have a say in whether a given person can reach a given application?

Firewall rules. A VPN. Perhaps an application gateway, perhaps a web gateway. Things published directly to the internet because at the time that was the pragmatic answer. SSO. MFA. MDM. Conditional access policies. And now, most likely, a cloud-delivered access platform bought in the last three years.

Most people get to seven or eight and become unsure whether they have missed one. That uncertainty is the finding. If the number cannot be stated confidently, nobody in the organization can answer the question those products exist to answer.

I wrote this in 2019

In March 2019 I published a post here called “The Madness of IT Security Sprawl”. I have just reread it, and the uncomfortable thing is not that parts of it are dated. It is that none of it is.

Here is what I wrote then:

“The reality is that the more security products you have, the more fronts you must defend. That complexity is magnified with every additional security product you throw at this tidal wave of attacks.”

And this, which I would now revise in only one respect:

“There is no truth to the commonly held belief that the more solutions deployed, the harder it is for an attack to be successful. That approach has been tried for the past three or four decades, and it still doesn’t work.”

The revision is the number. In 2019 it was three or four decades. It is now four or five.

The list, then and now

The 2019 post named what organizations were running. I listed: two-factor authentication, single sign-on, administrator access, partner access, customer access, file access, VPN, mobile device management, cloud access, RDP.

Read that list again and notice what is not on it.

No cloud-delivered access platform. No SASE. No agent governance of any kind. Those are the things that have been added since — and not one of the ten items on the original list has gone away in the meantime.

That is the whole argument in two lists. Seven and a half years, several new categories, nothing retired.

What I got right, and what I would say differently

The 2019 post said: consolidate your security. I still believe that, but the word has since been taken.

Every large vendor now sells consolidation. Platform, single pane, unified policy — the language is universal, and much of it is sincere. So “consolidate” is no longer a differentiating claim, and repeating it in 2026 would be joining a chorus rather than making a point.

What the chorus does not do is consolidate all of it. A platform consolidates the applications it can reach — and for most of them, that means the modern ones. The thick clients, the systems expecting a Kerberos ticket, the OT segments, the legacy applications behind an injected header stay outside, on whatever was there before.

Partial consolidation is not consolidation. It is a smaller number of larger pieces, which is an improvement in operations and no improvement at all in architecture. The platform becomes one more item on the list rather than a replacement for it.

That is the sharper version of the 2019 argument, and it took the intervening years to see it clearly.

It used to be one place

I have worked in IT since 1985. When I started, access control was centralized — not as a philosophy, but as a consequence. There was one system. A terminal, a mainframe, and one place that decided who could reach what.

Nobody called that an architecture. But it had a property worth naming: there was exactly one place where the question was answered, and therefore exactly one place to look when you needed to know the answer.

Everything since has been the story of losing that property, one reasonable decision at a time.

Forty years of partial fixes

Client-server distributed the decision across machines nobody controlled centrally. Connecting to the internet brought the firewall, to decide what could come in at all. Remote working brought the VPN — a second front door, with its own rules and its own administrators.

The VPN granted more than it should, so application gateways and web gateways arrived to constrain what happened after it. There were now too many places to authenticate, so SSO. Passwords stopped being sufficient, so MFA. The device stopped being ours, so MDM. The application stopped being ours, so cloud access brokers.

And when all of that still could not answer the question, the industry produced a new category to answer it properly.

Every one of those solved a real problem. Every one was, at the time, the right purchase. And every one answered part of the same question in a new place.

The seams grow faster than the products

This is why the estate feels harder to reason about every year even though each individual purchase was sound.

Three systems have three boundaries between them. Eight systems have twenty-eight. Each boundary is a place where two policy models meet and can diverge — and no boundary belongs to anybody. The team running each system owns the system. Nobody owns the space between them.

Policy divergence at those boundaries is not a failure of diligence. It is the arithmetic.

And nothing is ever actually removed

Products get replaced, in the sense that a newer one is bought. But the newer one covers a subset, so the incumbent survives for the remainder.

Look at what is still running in your estate right now. Firewall rules written by an engineer who left in 2017. An MDM deployment for a device population that has shrunk to forty handsets. A gateway kept alive for one application. A VPN that was supposed to be retired eighteen months ago.

None of it is anyone’s fault. Each was superseded rather than removed, because removing it entirely would have meant solving the awkward remainder — and the awkward remainder is always the expensive part.

The current generation is doing it again

Cloud-delivered access platforms cover what they can reach and leave the rest. The applications that could not move stay on the old path, and the old path stays with them.

That is not a criticism of a category. It is the same pattern, in the current decade, for the same structural reason. I have written separately about what it looks like from the inside — the question of why, after buying a modern access platform, you still have a VPN.

Why I think this is the breach story

I would argue — and it is an argument, not a citation — that this is the main reason breaches keep happening to organizations that are spending seriously on security.

Not because they underspend. Spending has risen steadily for two decades. Because the answer to “who can reach what” is distributed across a dozen systems that cannot see each other, and an intruder does not need to defeat that architecture. They need one seam between two parts of it.

Nobody is defending the seams, because the seams are not on anyone’s list.

The next one is already here

AI agents are being deployed into production estates now. They act on behalf of people. They hold credentials. They make requests at machine speed, against the same applications your staff use.

And a category of products is forming to secure them.

So here is the question worth asking before buying one: will governing what an AI agent can reach be a separate system from governing what a person can reach?

If the answer is yes, then to borrow my own words from 2019: that is one more front to defend. Humans decided in one place, agents in another, and a fresh seam between two populations that will increasingly do the same work against the same systems.

In five years someone will write a post about the AI access product nobody could remove, because it covered part of the estate and something had to stay behind for the rest.

The pattern never announces itself as a pattern. It arrives as a reasonable purchase, with a good demo, solving a real problem.

An AI agent is a principal making a request. If the place where access is decided already evaluates who is asking, in what context, against what policy, for every request — then an agent is another kind of requester, not another product category.

This is not nostalgia

The mainframe was not better. I am not proposing a return to 1985, and anyone who lived through it would not want one.

The point is narrower than that. One property of that era was worth keeping — that a single place decided who could reach what — and it was lost as a side effect of forty years of necessary changes, rather than because anyone decided it should be.

What has changed is that keeping it is now possible again. A single enforcement point can sit in front of the whole estate — and the word that matters there is whole.

The SaaS applications and cloud workloads a modern platform already handles well. The internal web applications. The thick clients. RDP and SSH sessions. OT environments. The legacy systems expecting a Kerberos ticket or an injected header. And the agents now arriving alongside the people.

That distinction is worth being precise about, because a product that covered only the difficult half would be another partial answer — one more item on the list, and exactly the thing this post argues against. The claim is not that we specialize in what others cannot reach. It is that one place decides, for everything.

Not as a migration. One population at a time, beside whatever is already there, until each old path has nothing left to serve.

Count them again in two years

That number should be going down.

For most organizations it has only ever gone up — and the next increment is already on the roadmap, wearing the word “AI”.

It does not have to. Stop the madness.

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.

That order is a decision. It was made a long time ago, by people solving a different problem, and almost nobody has revisited it since. But it is still being paid for — and the license is the smallest number in the story.

What the order costs

Consider what exists in a typical estate purely to constrain something that has already been granted.

Segmentation, to limit where a connected session can go. Micro-segmentation, because segmentation turned out to be too coarse. Network access control, to decide what is allowed to connect in the first place. Monitoring, to record where sessions went. Detection, to notice the ones that went somewhere they should not have. Lateral movement detection, which is a product category that exists because lateral movement is possible.

Every one of those is a sensible purchase in isolation. Each was bought by a competent person for a good reason. Together they represent a substantial share of a security budget, they each carry a console, a license and an owner, and they are all downstream of the same architectural choice: access is granted at the network level first, and constrained afterwards.

None of them are wrong. They are compensating controls, and what they are compensating for is the order.

So when the VPN comes up for renewal and the number looks reasonable, that number is not the cost of the VPN. It is the entry fee.

Why it never gets cheaper

The pattern is worth noticing, because it is the reason this line item grows every year and never shrinks.

Each layer is purchased to address the coarseness of the layer beneath it. Segmentation was too broad, so micro-segmentation. Rules became unmanageable, so a policy engine to manage the rules. Alerts outpaced the team, so a platform to triage the alerts. At no point is anything removed, because the thing beneath is still load-bearing.

This is the same accumulation described in “Stop the madness” — additions layered on additions — arriving here as a budget rather than as an attack surface. It is not a spending problem. The spending is the symptom.

Reverse the order

If a session reaches one application and no route onto the network exists, there is nothing to segment and nowhere to move sideways.

That is not a claim that detection and monitoring become unnecessary — you still want to know what happened, and no serious estate runs without them. It is a claim about how much work they are being asked to do. A control that constrains movement is doing very different work in an estate where movement was never possible in the first place.

The question this puts to any access product is a simple one: after it has decided, what does the session actually hold? A credential for one application, or a position on a network with an access control list drawn around it?

Where this is sharpest

Industrial and critical infrastructure environments, which is part of why they keep appearing in breach reporting.

Access into a plant network is frequently a VPN and a shared credential, with segmentation as the only thing standing between a contractor’s laptop and a controller. The access control was never designed. It was inherited — from a period when the plant network was not reachable from anywhere that mattered, and the assumption survived the thing that made it true.

The shape is identical in an office estate. It is simply less consequential when it fails.

And it has to be the whole estate

One caution, because this is where the argument is usually half-implemented.

Reversing the order for the applications that were easy to move, while the difficult ones stay behind a network-level path, does not reverse anything. It produces two orders running in parallel — per-application access for one group of systems, grant-then-filter for the rest — and the compensating control stack stays exactly where it was, because it is still holding up the half that did not move.

The saving is not in changing the order for some things. It is in not needing the compensating layer at all, and that only happens when there is nothing left underneath it. Which means the enforcement point has to be able to front the cloud and SaaS applications the organization has already modernized, the internal web applications, and the awkward ones that resisted every previous attempt — from one place.

The objection, which is correct

The VPN works. Everyone depends on it. Replacing it touches the whole organization at once, and the project would be judged on the week it went wrong rather than the two years it went right.

All of that is true, and it is why an architecture that everyone involved agrees is wrong outlives the people who inherited it. It is also why the sensible move is not a replacement. Total Access Control goes in alongside what is there and takes one population at a time — the mechanics of that are in “Why do you still have a VPN?”, and the point here is only that the order can be changed incrementally. It does not require a cutover date.

The order decides the blast radius — including for things you cannot see

There is a reason to settle this before the next wave of products arrives rather than after.

AI agents increasingly act inside sessions that a person opened legitimately. Whether any given one is identified, registered and well behaved is a separate question, and a real one. But what it can reach if it is not identified is decided entirely by the order.

On a grant-then-filter path, an agent operating inside an authenticated session inherits the network that session was placed on, and the compensating controls are the only thing standing in the way — the same controls that were already struggling with human sessions. On a per-application path, it inherits the application. Nothing about the agent changed. The ceiling did.

Products being built to govern agents will address identification. Very few of them will change what a session holds, and that is the half that determines the damage.

The question this raises

If someone had valid credentials for your VPN this afternoon, how far would they get before anything stopped them?

If the honest answer is “further than I would like, but segmentation would probably contain it”, that is the compensating control doing the work the architecture should be doing — and you are paying for both.

That single fact removes every control the rest of your estate depends on, and the usual answers are all attempts to get it back. Ship them a laptop, and you have spent procurement, imaging, shipping and recovery on one application — and the device is out of your sight for six weeks. Make them install an agent, and their IT may refuse, their security policy may prohibit it, and a supplier with leverage will simply decline. Give them a VPN account, and you have placed an unmanaged machine on your network with an access control list as the only thing deciding where it can go.

And when all three are slow enough or contentious enough, the fourth answer happens instead: an account gets shared, a screen-share becomes the access method, or the data is extracted and emailed and now sits on that machine permanently with nothing attached to it at all. That one never appears in an access review, because from the system’s point of view no access was granted.

The part that cannot be fixed

Underneath all four is the same condition, and it is worth stating plainly because it does not go away.

You cannot see what is on that device. Not the browser extensions, not the assistant with access to their desktop, not the tools they connected to their own accounts last month, not whatever arrived with them. You cannot inventory it, you cannot mandate what may be installed, and anything the machine reports about itself is a claim from a system you do not control.

This is a permanent condition, not a gap waiting for a product. Every approach that depends on knowing what is running on the endpoint — including the emerging model for governing AI agents, which asks agents to register and declare themselves — is defeated here by definition. No registry you deploy covers a contractor’s laptop.

So change the question

The question is not how to make an untrusted device trustworthy. You cannot, and the effort spent trying is the reason third-party access takes six weeks to arrange.

The question is how much it matters that it is untrusted — and that is entirely within your control, because it is decided by what the session is allowed to be, not by what the device is.

There are four ways to reduce it. They apply in order, and they compound.

First and second: validate, then bound

We have covered these two before, so briefly.

The session is established against the enforcement point, where identity, authentication strength, context and whatever device signals are genuinely available are evaluated — at the point of access, per request, rather than on an endpoint you cannot instrument. Then the session is given the resource rather than the network: it reaches the one application it was granted and receives no route onto anything else, because there is no route to receive.

The consequence is the one we described when we wrote about contractor and third-party access last February. Whatever is riding along inside that session — an assistant the contractor connected, malware they do not know about, an agent that never declared itself — is confined to exactly what the contractor was granted. Not because it was detected. Because there is nowhere else to go.

One caveat worth stating plainly, because it is the claim a technical reader will test: the device signals available from an unmanaged machine are not the signal set a managed endpoint produces, and any vendor telling you otherwise is selling you something. The comparison that matters is not with a corporate laptop. It is with the VPN account that was the realistic alternative, which asked nothing at all.

Third: move the critical path off the device entirely

For the access where bounding the radius is not enough, there is a further step, and it is the one that changes the risk rather than limiting it.

The application is published so that it executes in a controlled environment you do own — delivered to the contractor as a remote session rather than run on their machine. They interact with it. The application, its data and its credentials never land on the endpoint. What they are holding is a window.

This is the answer for the access that would otherwise be refused outright: an administrative tool, a system holding regulated data, the thing a supplier needs that nobody is comfortable exposing. And critically, it is applied after the session has been identified and validated against policy, not instead of it. Isolation is where a validated session is placed. It is not a way of skipping the validation.

Fourth: set the terms of the session yourself

Which raises the question a security reviewer asks immediately, and it is the right question. A remote session that permits clipboard, drive mapping and printing has moved the application off the device and handed the data straight back.

So those are not defaults to be inherited. They are parameters, and Total Access Control carries them into the session it publishes — what may be copied, what may be printed, whether local drives are mapped, what the window is permitted to do at all. The terms of the remote session are set by your policy rather than by whatever the endpoint or the protocol would allow if nobody specified.

And the same applies to getting data out through the ordinary path. File download can be filtered on authentication strength, device posture and context — so the capability is not a property of the application, it is a property of this session, opened by this person, from this device, in these circumstances.

That conditionality is what makes the whole thing workable commercially, because it means you rarely have to answer no.

The supplier who will not install an agent is not refused. They are given a session with no clipboard, no drive mapping, no printing and no download, into an application running somewhere you control. The same person, later, from a managed device with stronger authentication, gets a session with more in it. Nobody negotiated. Nobody made an exception. The policy simply produced a different session, and both are recorded the same way.

That is the graduated response. Ordinary access gets a bounded session. Sensitive access gets an isolated one. Risky context gets an isolated one with the exits closed. Every one of them is a policy decision on the same platform, made per user, per application, per context — rather than a separate product bought for each tier of risk.

And all of it stays in one place

None of the above is a separate product, and that is the part that matters more than any individual control.

Solving third-party access by buying a dedicated third-party access product solves third-party access and leaves the estate worse — another console, another policy model, another set of logs that has to be correlated with the others during an audit. That is exactly the pattern that produced the sprawl in the first place.

The same enforcement point that handles the contractor handles employees, remote administrators, an OT segment, the cloud and SaaS applications already running well, and the internal applications nobody could move. One policy model. One set of logs recording what was actually reached, by whom, on what. One place to answer an auditor, and one place to change your mind when the contract ends.

Third-party access is simply the case where the argument is easiest to see, because it is the case where you can watch every assumption fail at once.

Where to start

Take the third-party access path you would least like to explain to an auditor, and ask two questions about it.

What does this grant beyond the one application it exists for — and if that machine is already compromised, what have we actually lost?

It is not an unreasonable request. It is close to the most ordinary request in security operations, it comes up in audits, investigations and offboarding reviews, and most organizations can eventually answer it. The word doing the work in that sentence is “eventually”.

What comes back first

The first answer is a list of authentication events. This person connected at these times, from these addresses, with these methods, and the connection was permitted.

That is a real record and it is genuinely useful. It also does not answer the question that was asked. The question was what they reached; the answer describes that they were admitted.

The distinction is easy to lose because the system producing those records is usually called an access log. It is an admissions log. Everything it knows, it learned at the door.

Why the record stops at the door

This is not a logging deficiency, and it will not be fixed by increasing the log level.

If a product evaluates a request at connection time, establishes a path, and then steps out of the way, its records can only describe what it observed — and what it observed was the connection. The traffic that followed did not pass through it. There is nothing for it to withhold.

A component that remains in the path for the duration of the session is in a different position. Every request traverses it, so its record can describe resources rather than admissions.

Same question, two architectures, two different kinds of answer — and the difference is decided long before anybody configures logging.

So the answer gets assembled

Because the primary record is incomplete, the real answer is built from fragments. Everybody who has done this recognizes the shape of it.

Connection records from the remote access platform, to establish when the person was on. Application logs from each system they might have used, in whatever format each one produces. Directory group membership, to determine what they could have reached — though membership today is not membership in April. Jump server records, if there is a jump server. Possibly a ticketing system, to establish what they were supposed to be doing.

Then somebody correlates it. Timestamps in different zones, identifiers that differ between systems, a person whose account name changed when they moved teams.

It is skilled work, it takes days, and it is done under time pressure by people who had other commitments that week. The output is a narrative rather than a record — and a narrative assembled by inference is a weaker thing to hand an auditor than a record that was simply kept.

The gaps are structural

The harder problem is what correlation cannot recover.

If a session reached a system that produces no useful application logging — and the applications that resisted modernization are disproportionately in that group — then nothing anywhere recorded it. The remote access platform saw a connection. The application recorded nothing worth having. The access happened and left no trace.

The honest answer to “did they reach this system?” is then “we cannot tell”, which nobody wants to write down and almost nobody does. What gets written instead is what the evidence supports, with the systems that produce no evidence quietly absent from the report.

This is the part worth sitting with. The absence is invisible. A report assembled from the systems that keep records looks complete, because the systems that keep no records contribute nothing to it — including no indication that they are missing.

The three questions, and which ones you can answer

Audit requests reduce to three, and they have different evidentiary requirements.

Who had access to this system? Answerable from entitlements rather than logs, provided entitlements are reviewed and the review is evidenced. Most organizations manage this one.

Who used it, and when? Requires records tied to the resource rather than to the connection. This is where the assembly work starts.

What did they do while they were there? Belongs to the application, if it keeps such records and if they can be correlated to the person rather than to a service account.

An admissions log answers the first and gestures at the second. The gap between what the second question needs and what the connection record provides is the whole of the correlation exercise.

What a record kept at the right place looks like

If the enforcement point is in the path of every request, the request and the resource are in the same record, because it saw both.

That is the entire difference. Not a superior logging implementation — a position from which the useful facts are observable in the first place. Total Access Control terminates the session in front of the resource, so what it records is per-resource rather than per-connection, for every application it fronts.

The practical effect is that the quarter-of-a-contractor question becomes a query rather than a project. Which matters less for the audit than for everything else: the same record is what an investigation needs at two in the morning, and it is what a manager needs when somebody asks whether a leaver still had access to the thing they should not have.

A test worth running before someone asks

Pick a person and a quarter. Ask for everything they accessed, across every system, and note how long it takes and how many sources it draws on.

Then ask the harder half: which systems could they have reached that would not appear in that answer at all?

The first number tells you what an audit will cost. The second tells you what it will miss.

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.

Not “do you enforce multi-factor authentication?” — but “on what proportion of the systems a person can actually reach?”

Every answer was true

Consider how an assessment usually goes.

Is multi-factor authentication enforced for remote access? Yes. Is access reviewed periodically? Yes. Is remote access encrypted and logged? Yes. Are privileged accounts subject to additional controls? Yes.

Every one of those answers is true. The control exists, it is documented, it operates, and the evidence is real. Nobody is being evasive, and the person answering is describing the estate accurately as they understand it.

What the questions establish is that a control exists somewhere in the organization. What they do not establish is what it covers.

How the gap opens

No control is deployed everywhere on day one. It goes where it can go.

The modern applications take it easily. The web estate follows. Then the program reaches the systems that were never designed to participate in any of this — an application that expects its environment to have already established who the user is, a thick client, a vendor-supported system where any change to the configuration voids the support agreement, an operational segment where the device opens the session rather than the person.

Those become exceptions. Each one is logged, justified, approved, and given a review date. That is the process working correctly — an exception register exists precisely so that the things which cannot comply are visible rather than hidden.

Then the review date arrives, the underlying reason has not changed, and the exception is renewed. It is renewed again the following year by someone who was not there for the original decision and has no basis to refuse.

The control is real. The exception is real. They are simply recorded in different places, discussed by different people, and never added together.

This is not a criticism of the frameworks

Worth saying plainly, because it would be easy to read this as an argument that compliance is theater. It is not.

Frameworks are scoped deliberately. They assess whether a control is designed appropriately and operating effectively, which is a reasonable thing to assess and a hard thing to do well. Auditors are not architects, they are not commissioned to redesign your access model, and an assessment that attempted it would be worse, not better.

The gap is not a failure of the audit. It is that the audit was never the instrument for this, and organizations quietly treat it as though it were. A clean report becomes the answer to “are we protected?”, when what it answered was a narrower and more specific question.

The test that takes an afternoon

Here is a way to find out where you stand, and it requires no tooling.

Take one control you attest to — multi-factor authentication on remote access is the usual candidate. Now ask for the list of systems it does not cover.

Not the exception register, which records the ones somebody wrote down. The actual list: everything reachable by a person, minus everything behind that control.

Three things tend to happen. The list takes far longer to produce than anyone expected. It is assembled from several sources that disagree. And it is longer than the person who attested to the control believed it would be.

If nobody in the organization can produce that list in an afternoon, then the attestation describes a control rather than an estate — and the difference between those two things is where incidents live.

Why the gap is worse than its size suggests

If the uncovered systems were a random sample, this would be a smaller problem.

They are not random. They are the systems that resisted every modernization attempt, and the reasons they resisted — age, bespoke authentication, vendor constraints, operational sensitivity — are highly correlated with importance. Administrative interfaces. Production and operational systems. Things holding regulated data that nobody was willing to disturb.

The strongest controls end up on the systems that were easiest to protect, and the weakest sit in front of the ones that would matter most. Nothing in an assessment surfaces that inversion, because the assessment examines controls one at a time.

What actually closes it

A control that cannot be deployed everywhere will always produce exceptions, and exceptions will always become permanent. So the question is not how to manage the register better. It is what would remove the need for it.

An enforcement point that sits in front of the whole estate — not the convenient part of it — makes coverage an attribute of the architecture rather than a program to be run. Total Access Control is built for exactly that position: it fronts modern applications and the ones that expect identity presented in an older form, so the systems that generate exceptions stop generating them.

The practical consequence is that attestation gets simpler rather than harder. One enforcement point, one policy model, one record of what was reached — pointed at once, rather than assembled from six systems and a spreadsheet each time somebody asks.

The question to ask before the next assessment

Not: will we pass?

But: when we attest to a control, do we know what it covers — and could we prove it this week without anyone working a weekend?

Most security tools are built for the security team. TAC is built for everyone — and that distinction matters more than most people realise. When access is simple, consistent, and friction-free, users actually follow the rules. They don’t look for workarounds. They don’t share credentials because logging in is too complicated. They just work.

This is the story of what it’s actually like to use TAC as an end user — and why that experience translates directly into productivity, satisfaction, and measurably better security outcomes.

One Place for Everything

When a user logs into TAC, they see one thing: their portal. Every application they’re authorised to use is right there — cloud applications, on-premises systems, legacy tools, thick-client applications, internal databases — all in one place, all accessible with the same login.

There is no list of different URLs to memorise. No separate login for the VPN, another for the HR system, another for the file server, and yet another for the cloud platform. No mental map of which system requires which credential or which MFA method. TAC replaces all of that with a single, unified experience that feels less like a security product and more like a well-organised desktop.

Users click the icon for what they need. That’s it.

Single Sign-On That Actually Works — Everywhere

TAC delivers true Single Sign-On across every application in the portal — not just the modern, cloud-friendly ones. Authenticate once at the start of your session and TAC handles the rest. Whether you’re launching a cloud-based CRM, connecting to a legacy ERP system that hasn’t been updated in a decade, or opening a thick-client engineering tool, the experience is identical: click, connect, work.

This matters enormously in practice. In most organisations, users re-authenticate multiple times a day across different systems — each with its own login screen, its own password policy, its own MFA prompt. That friction compounds into real productivity loss. Studies consistently show that authentication overhead and password-related interruptions can consume 20 or more minutes per user per day across an organisation.

TAC eliminates that entirely. One authentication. Every application. All day.

A Portal That Adapts to You — Without Asking You to Do Anything

One of the most underappreciated aspects of TAC is how much it does invisibly. The portal isn’t static — it adapts dynamically to the user’s context on every session. TAC continuously evaluates device posture, network location, and identity status, and adjusts what the user can access accordingly.

A user working on a managed device from the corporate network might see their full application suite. The same user on a personal device from a coffee shop might see a subset of applications appropriate to that context. A contractor logging in from an approved device in an approved location sees exactly what they’re authorised for — nothing more, nothing less.

None of this requires the user to understand policy, navigate configuration screens, or make any decisions. TAC handles the evaluation automatically, on every request, in real time. The user simply sees what they should see for their current situation — and gets on with their work.

This is what intelligent, context-aware access looks like from the user’s perspective: it just works, appropriately, every time.

You Don’t Need to Know Where Anything Lives

Here is something most enterprise users have learned to accept as normal: knowing which applications live in the cloud, which ones are on the company server, and which ones require the VPN to be connected first. It’s a constant low-level cognitive overhead, and it creates a daily stream of minor frustrations when something doesn’t connect the way the user expected.

TAC removes that overhead completely. Users don’t need to know — or care — whether an application runs in a local datacenter, a private cloud, a public cloud, or somewhere in between. TAC abstracts all of that away behind a consistent interface. The icon for the inventory system looks the same whether that system is running on a server three floors below or in a cloud region on the other side of the world.

And critically: when things change, users don’t have to adapt. If IT migrates an application from the on-premises datacenter to the cloud, the user’s experience is completely unchanged. Same icon. Same login. Same URL if they were using one. No announcement, no retraining, no helpdesk tickets from users who can’t find the application anymore. The migration is invisible to the people it most affects.

For organisations in the middle of cloud migration programmes, this is genuinely transformative. Infrastructure teams can move workloads on their own timeline without coordinating change communications and retraining exercises for every application they move.

The Same Experience In the Office and on the Road

For many organisations, remote and hybrid work has created a two-tier access experience: the comfortable, predictable in-office experience and the frustrating, inconsistent remote one. VPNs that disconnect at inconvenient moments. Applications that don’t respond properly over split-tunnel connections. MFA prompts that work differently depending on where you are.

TAC provides the same experience regardless of where the user is working — provided they meet the appropriate security requirements for their context. A road warrior in a hotel, a remote employee at home, and a staff member at their office desk all see the same portal, with the same interface, and access the same applications they’re authorised to use.

There is no separate remote-access workflow to learn. No VPN client to launch first. No remembering which applications work remotely and which ones don’t. TAC simply is the access layer — everywhere, consistently.

Almost No Training Required

One of the most telling indicators of a well-designed user experience is how little explanation it requires. TAC consistently generates feedback from IT teams that end users needed little or no formal training to start using it effectively. The interface is intuitive because it is simple: log in, see your applications, click what you need.

For many deployments, user communications consist of a single email: “Starting Monday, you’ll access your applications through this new portal. Your login is the same as always.” That’s frequently sufficient. No training sessions. No video walkthroughs. No helpdesk surge.

For organisations rolling out TAC to large user populations, this translates into significant savings — not just in training costs, but in the productivity loss that typically accompanies major system changes. When users don’t need to learn a new way of working, they don’t lose time adapting to one.

MFA That Fits the Workflow

Multi-factor authentication has a reputation problem. In many environments, MFA means a different app for each system, authentication fatigue from repeated prompts throughout the day, and the constant minor friction of approving push notifications before getting to the actual work.

TAC supports a wide range of MFA methods — FIDO2 hardware tokens, push notifications, TOTP apps, SMS, biometrics, and more — and applies them once at session authentication. Once they’re in, they’re in — across every application in the portal, for the duration of their session.

The result is stronger authentication overall, applied more consistently, with less user friction than most organisations achieve with their current approach.

Security That Works With Users, Not Against Them

There is a well-documented dynamic in enterprise security: when security controls are too burdensome, users find ways around them. They write passwords on sticky notes, share credentials with colleagues, leave sessions open indefinitely, or simply stop using required tools because the friction is too high. Security measures that create excessive overhead don’t make organisations more secure — they push behaviour into the shadows.

TAC takes the opposite approach. By making the secure path the easy path, it encourages the behaviours that actually improve security posture. When users don’t have to manage multiple credentials, they don’t share them. When MFA is straightforward and applied once, users don’t resent it. When the access experience is consistent and reliable, users trust it — and use it.

The organisations that get this right understand that user experience is a security control in its own right. TAC is designed with that understanding built in.

The Bottom Line for Users

TAC gives users something that feels increasingly rare in enterprise technology: an experience that respects their time and doesn’t require them to think about infrastructure. They log in once. They see their applications. They get to work. Whether they’re at their desk, at home, or in an airport lounge — whether the applications they need are running on servers in the building or in a cloud region they’ve never heard of — the experience is the same.

For IT teams, this means fewer helpdesk calls, smoother rollouts, and users who actually comply with access policies because those policies don’t get in their way. For end users, it means less frustration, more time on the things that matter, and a relationship with enterprise technology that feels more like a tool than an obstacle.

That, in the end, is what good access control looks like.

Enterprises are deploying AI agents at scale. Almost none of them are governing what those agents can access — or even know what they are doing.

There is a conversation happening in every security team right now about AI. Most of it is about the wrong thing.

The dominant concern is data exfiltration through chatbots — employees pasting sensitive documents into consumer AI tools. This is a real problem. But it is a people-and-policy problem, and people-and-policy problems have people-and-policy solutions.

The problem that is not getting enough attention is structural and architectural. It is the problem of non-human identities operating inside your enterprise infrastructure with permissions that nobody designed, oversight that nobody implemented, and an audit trail that does not exist.

What an AI Agent Actually Is

An AI agent is a software system that takes actions autonomously to complete goals. It is not a chatbot that answers questions. It is a process that calls APIs, queries databases, reads and writes files, sends emails, creates tickets, modifies records, and chains these actions together in sequences that no human explicitly approved.

Enterprises are deploying these systems today — for customer service automation, code review, data processing, report generation, and HR workflow orchestration. Almost none of these deployments have meaningful access controls.

The Identity Gap

When you deploy a human employee, you give them an identity. You create an account in your directory. You assign them to groups. You provision access to specific applications based on their role. Their actions are logged against their identity.

When most organisations deploy an AI agent today, they give it a service account with a static API key, broad permissions, no MFA challenge, no device posture check, no continuous evaluation, and no meaningful audit trail. The API key has the same access every minute of every day, regardless of what the agent is doing or whether its behaviour has changed.

These are real attack vectors:

• Prompt injection — malicious content in documents instructs the agent to take actions outside its intended scope
• Privilege escalation — an agent with broad API access can be manipulated into accessing systems far outside its intended workflow
• Lateral movement — agents that can chain API calls can traverse systems in ways that would be obvious if a human did the same thing
• Data exfiltration — an agent with read access to sensitive data and write access to an external API is a data exfiltration tool waiting for a trigger

Why Existing Tools Cannot Solve This

The identity platforms built for human users are poorly suited to governing AI agents. The fundamental mismatch is that human identity platforms assume an interactive principal — someone who can receive an MFA challenge and respond to an authentication prompt.

AI agents are non-interactive. They authenticate programmatically, operate continuously, and make thousands of access decisions per hour. What AI agents need is identity verification, resource-level permissions, continuous evaluation, and a complete audit trail — a different problem set requiring different tooling.

The Right Architecture

The correct approach is to govern AI agents and human users through the same policy engine — with agent-specific policies that reflect the different nature of non-human access.

An AI agent that processes invoice approvals should have access to the invoice processing API, the approval database, and the notification service. It should not have access to employee records, code repositories, or customer databases — even if those systems are technically reachable. Its access should be scoped to exactly what its workflow requires, evaluated on every request, and logged with enough detail to reconstruct exactly what happened and why.

When the agent starts behaving outside its expected pattern — accessing resources it has never touched before, making requests at unusual times, chaining API calls in anomalous sequences — that deviation should trigger immediate evaluation and potential access revocation.

The Window Is Closing

The time to build governance for AI agents is before the incident, not after. The organisations that deploy agents with broad static API keys and no oversight are accumulating risk faster than they realise. The good news is that the architecture to solve this already exists.

TAC’s AI Agent Access Control is coming next — governing non-human identities with the same policy engine that protects your human workforce. See how it works →