Somewhere in your infrastructure there is a VPN account created for an integrator three projects ago. The password is shared between an unknown number of people at a company you no longer work with. Nobody recorded what it was used for. Nobody remembers it exists (except, possibly, whoever ends up with it next).
This is not a hypothetical. Verizon's DBIR 2025 found third-party involvement in 30% of breaches, double the previous year's share. The pattern behind those numbers is depressingly consistent: credentials reused or stolen in a supplier's environment, walking straight through the customer's front door.
Why the VPN + shared account model keeps failing
The traditional recipe for vendor access fails on four separate axes at once:
- Identity is unknown. A shared "vendor_support" account tells you a company connected, not which person, and not whether they still work there.
- Duration is unlimited. VPN accounts are provisioned for a project and live forever. Access outlasts the contract, the engagement, sometimes the vendor itself.
- Nothing is recorded. A VPN grants network presence, not a supervised session. What happened between login and logout is anyone's guess.
- Offboarding depends on memory. The vendor's engineer changes jobs; nobody tells you. Your offboarding process covers employees, not other companies' employees.
Regulators have caught up with all four. NIS2 explicitly extends MFA, least privilege, and session monitoring requirements to supplier access. In OT environments, IEC 62443-2-4 makes secure vendor remote access an evaluation item in its own right. If you operate critical infrastructure, "the integrator VPNs in" is no longer an acceptable answer to an audit question.
What vendor privileged access looks like instead
Vendor privileged access management treats an external engineer as a first-class, temporary identity rather than a hole in the firewall:
- Invite, don't provision. The vendor is invited by email: name, company, purpose, time window. No AD account, no VPN profile.
- Sponsor approval. Activation lands with the inviting employee for approval, so every external identity has an internal owner who said yes.
- Passwordless first login. The vendor activates through a magic link and steps up with MFA: no password to share, reuse, or phish.
- Vendor organizations and delegation. The vendor's team lead onboards their own engineers within the limits you set; each person is individually identified, and the whole organization can be cut off at once.
- Just-in-time, recorded sessions. Access is granted per target and per time window, opens through a brokered session that is fully recorded, and expires on its own: zero standing privilege, applied to outsiders.
- Evidence built in. Who invited whom, who approved, who connected where, and what they did, all available as reports and attestation, mapped to the frameworks your auditors ask about.
Notice what disappeared: the VPN, the shared account, the "please remember to disable it" ticket.
The market already treats this as its own discipline
Analysts track vendor PAM as a distinct segment, and every major PAM vendor sells it as a separate product with a separate price tag. It shows up as its own section in RFPs. That is worth knowing for one practical reason: if you are evaluating privileged access platforms, vendor access is a capability to check for explicitly, not something to assume comes in the box.
Where Monofor fits
Monopam builds vendor access into the same platform that handles your internal privileged access: invitation with sponsor approval, Magiclink activation and MFA through Monosign, vendor organizations with delegation, just-in-time time-bound grants, session recording on every connection, and attestation reports: no VPN, no shared credentials, no separate SKU. The full picture is on the external partners solution page.
Your vendors need access. They do not need your network.
Further reading: Standing Privileges Are a Renewable Risk and the vendor privileged access glossary entry.
