Every enterprise depends on outsiders: the hardware vendor who maintains the storage array, the application vendor who patches the core system, the system integrator running the upgrade project. Each of them, at some point, needs privileged access to something critical. The standard answer for years was a VPN account and a shared credential - which is to say, unsupervised network presence for people the organisation does not employ, cannot discipline and rarely monitors. Third-party engineers with VPN credentials and no supervision have been the entry point in some of the most damaging breaches on record.
The enterprise challenge: access you must grant to people you cannot manage
Vendor access combines every hard property of privileged access at once. The users are external, so identity assurance is weaker and offboarding is invisible - the vendor reassigns an engineer and nobody tells you. The access is intermittent, so standing VPN accounts sit dormant between engagements, unpatrolled. The work happens on the most critical systems, because that is what vendors are hired for. And accountability is contractual rather than managerial: when something goes wrong during a maintenance window, the discussion is word against word unless there is a record.
Why VPN-plus-credentials fails this problem
A VPN grants network presence, not scoped access - once inside, the vendor can typically reach far more than the one system they came for. Shared credentials sever attribution: the target logs a generic account, not a person. Standing accounts violate the intermittent nature of the need. And nothing in the arrangement produces evidence of what was actually done. Each of these gaps is precisely what a privileged access layer exists to close.
The Tanflow approach: time-boxed, recorded, policed - and nothing to install
Tanflow PAM treats vendor access as a first-class pattern. The vendor engineer never receives network presence or credentials at all. Instead:
- Time-boxing: Just-in-Time access grants a window scoped to the engagement - in Tanflow's own illustration, a hardware vendor gets RDP to one jump target for Tuesday's maintenance, and the access is gone by Wednesday. Expiry is automatic; no offboarding step can be forgotten.
- Change management: the access is requested with a reason and approved through the platform, so every vendor window traces to a documented, authorised purpose.
- Credential injection: the vault injects target credentials into the session; the vendor never sees a password, so nothing exploitable leaves with them.
- Full recording: the browser-based session is recorded end to end at the gateway, with command logs - evidence, not recollection.
- Command control: real-time policy polices what the vendor can do, with graduated verdicts - destructive commands can terminate the session and alert the SOC, sensitive operations can demand logged justification.
Because Tanflow PAM is zero-agent, none of this requires software on the vendor's laptop or on the target - a browser reaching the gateway is the entire client footprint. That matters doubly for third parties, whose devices the enterprise cannot manage. For supervision, session sharing lets an internal engineer watch the vendor session live, read-only or interactively, without credentials changing hands.
The vendor access workflow
- The engagement owner requests access for the vendor: specific target, specific protocol, specific window, stated reason.
- Approval is granted through change management and logged.
- During the window, the vendor engineer signs in to the PAM portal - with MFA - and works in a recorded, policy-enforced browser session with injected credentials.
- The window expires; access ceases automatically; the recording, command log, request and approval remain as a complete file on the engagement.
Enterprise scenario
Consider a power utility whose substation-adjacent enterprise IT and metering systems are maintained by multiple OEM vendors - a sector where supervised vendor access is a named regulatory concern. Routed through Tanflow PAM, each vendor's quarterly maintenance becomes a bounded, watched, replayable event. When the utility's auditor asks how third-party access is controlled and evidenced, the answer is a report from the platform: every window, its approver, its recording.
Security and audit implications
Vendor access under PAM inverts the trust problem: instead of trusting the vendor's people, devices and offboarding processes, the enterprise trusts its own gateway, its own policies and its own recordings. The dormant-account attack surface disappears with time-boxing; attribution is restored by named portal identities; and the evidence auditors ask for - who, when, why, what exactly - is generated as a by-product of the access itself.
Conclusion
Third-party privileged access will always be necessary; unsupervised third-party access no longer is. By combining JIT time-boxing, change approvals, credential injection, full recording and real-time command control - all through a zero-agent gateway - Tanflow PAM lets enterprises give vendors exactly the access the engagement requires, watch it happen, and prove afterwards that nothing else occurred.