A contractor needs one application for six weeks. The machine they will use belongs to them.
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?