The attacker doesn’t come for you. They come for the company you let in.
Breaking into a well-defended organisation is expensive. Breaking into the consultancy that holds privileged access to forty well-defended organisations costs about the same, and it only has to work once.
So the target moved. Managed service providers, IT consultancies, implementation partners, maintenance contractors — anyone whose business is holding credentials to other people’s systems is now worth more to an attacker than most of their clients are individually.
What the attacker ends up with is not an exploit. It is a valid account on your side, with a legitimate reason to be there.
| What you’d normally look for | Why it doesn’t fire here |
|---|---|
| A failed authentication pattern | The credential is correct. You issued it |
| Access from an unexpected place | The supplier has always connected from outside. That is the arrangement |
| Activity outside normal hours | Vendor work happens at odd hours by nature — that is when the maintenance window is |
| Something that doesn’t match the contract | It does match. They are reaching the system they support, doing the work they do |
You can’t secure your supplier. You can only decide what their access is worth if somebody takes it.
How the access got there in the first place
None of this requires anybody to have been careless. The access was needed on a deadline, and creating a VPN account takes minutes while setting up a governed, recorded, time-bound route takes a conversation with two teams. It outlived the project, because nobody owned the decommissioning — the account belongs to a company, and leaver processes are built around employees. It got shared inside the supplier, because it was issued to a firm rather than a person, so whoever is on shift uses it. The device was never in scope. And what was granted was reach, not access — a VPN plus a firewall rule written for a system that has since moved.
The number that ends the discussion. Count the supplier accounts whose last logon is more than 180 days ago and which are still enabled. Each one is an open door held by a company you may no longer have an active project with, protected by a password that may have left with an engineer you were never told about.
A session to a named system, not a route onto your network
The change that matters is what gets granted. Not a subnet, not a route, not an interface on their machine — a session to the specific systems they are mapped to, and nothing else reachable from it.
Their laptop never joins your network. There is no route added to their machine, so there is nothing to misconfigure later and no firewall rule that quietly grants more than it used to.
- Nothing installed on their side The session runs in Mirket's isolated browser. For a supplier this is the right path precisely because it asks nothing of a device you don't control and can't inspect.
- Nothing installed on your targets Appliances, embedded systems and equipment under warranty often can't host software at all. The control sits in the access path, so they are covered on the same terms as a server.
They never receive the credential
The engineer authenticates as themselves. The system’s password is injected into the session, so it is never rendered to them, never typed on their laptop and never saved in whatever they keep passwords in.
The consequence is the one that saves the most work: when their staff change, nothing on your side needs rotating. You are not told when an engineer leaves a supplier. With injected credentials you do not need to be.
Access with an end date and a name on it
Vendor access is periodic by its nature, which makes it the clearest case on the estate for granting access to an afternoon rather than to a contract.
A session policy’s action can be JIT: the engineer requests a window with a stated reason, somebody on your side approves it, and it expires on the clock. Approvers can be several people so that a request doesn’t wait for one person to wake up, and an approved window can be revoked early if circumstances change. Just-in-Time Access covers the mechanics.
Recorded, and attributable to a person
Access issued to a company cannot be attributed to anybody, because companies do not sit at keyboards.
Every session is recorded as video and as a searchable command transcript, tied to the individual Mirket authenticated. This protects both parties — a disputed change after a vendor session becomes a recording rather than two recollections and a commercial argument.
From outside, without anything listening
Suppliers connect from their own networks, which is where a VPN concentrator usually earns its place — and its exposure.
With Mirket ZTNA, the connector inside your environment dials outbound, so there is no inbound port published to the internet. The engineer reaches an authorised application rather than a network, and the session is authorised again each time rather than trusted because a tunnel came up earlier.
Ending it is one action
When the contract ends, access should end — not be discovered during an audit two years later.
Because access is a policy on the platform rather than an account plus a firewall rule plus a local login on a piece of equipment, ending it is one action in one place. That is the difference between an end date that holds and one that depends on somebody eventually noticing.
What changes with Mirket
| Before | With Mirket |
|---|---|
| A VPN account and a firewall rule | A session to one named system |
| The supplier’s laptop is on your network | It is on a web page |
| Access issued to a company | Sessions attributable to a person |
| The account outlives the contract | The window expires on its own |
| Their engineer leaves with your password | They never had it |
| A disputed change, and two recollections | A recording |
| A supplier compromise reaches your network | It reaches one session, inside a window, on camera |
| Equipment that can’t run an agent stays outside everything | It is covered without anything installed on it |
| Ending access means hunting through rules and devices | It is one action in one place |
Frequently asked questions
Why is third-party access treated as a special case?
Because the compromise happens somewhere you cannot see. The laptop was never inspected by you, the security programme was never audited by you, and the password policy was never read by you. What arrives on your side is a valid account with a legitimate reason to be there.
What's wrong with giving a supplier a VPN account?
A VPN grants a route rather than access. Their device joins your network, and what becomes reachable is decided by firewall rules written for a system that has probably moved since. It is also the fastest thing to set up under deadline pressure, which is why it keeps winning.
Does the supplier have to install anything?
No, and this is usually the deciding factor. Asking a supplier to put your agent on their engineer's laptop tends to fail — it is their asset, their policy, and they work for several clients. The session runs in Mirket's isolated browser, so their machine needs nothing but a browser.
Does this mean opening a port for them?
No. Replacing a VPN concentrator with a different inbound port would not be progress. With Mirket ZTNA, the connector inside your network dials outbound, so there is nothing listening on the internet for anybody to find.
Does the engineer ever hold our password?
No. They authenticate as themselves and the system's credential is injected into the session. That has a useful consequence: when the supplier's staff change — and you will not be told — there is nothing on your side to rotate.
How do we stop vendor access outliving the project?
By not granting it permanently in the first place. Vendor work is periodic by nature, which makes it the clearest case for just-in-time access: a window with a stated reason, an approver on your side, and an expiry that does not depend on anyone remembering.
What happens when a supplier's engineer leaves?
Nothing on your side needs to change, because they never held a credential of yours. Compare that with a shared VPN account, where their copy of the password leaves with them and you find out during an audit.
Can we prove what a vendor did during a session?
Yes, and it protects both sides. Every session is recorded as video and as a searchable command transcript, attributed to the person your platform authenticated rather than to a company name. A disputed change becomes a recording rather than two recollections.
What about equipment that can't run an agent at all?
Appliances, embedded systems and anything under a vendor warranty often cannot host software. Nothing is installed on the target in any case — the control lives in the access path — so that equipment is covered on the same terms as everything else.
How do we end access when the contract ends?
As one action on the platform, rather than by hunting through firewall rules, VPN profiles and local accounts on equipment. That hunt is the reason supplier access is usually ended by an auditor rather than by a contract date.
Is a supplier questionnaire not enough assurance?
It answers a different question. A questionnaire asks whether a supplier holds a certification; it does not ask what their engineers can reach inside your environment, or how many other client networks the same laptop reached this week. The lever you actually hold is what the access can do.
Related
Solutions — Just-in-Time Access · Privileged Remote Access · RDP & SSH Session Recording · Web & Desktop Application Access · Session Control & Command Policy
Products — Privileged Access Management · Zero Trust Network Access
Industries — Manufacturing · Healthcare