External access doesn't inherit internal safeguards automatically
When a vendor, contractor, or support partner is granted access to internal systems, that access exists inside the organization's infrastructure but the person holding it exists outside the organization's normal processes — no onboarding checklist, no manager tracking their role changes, no automatic trigger when their engagement ends the way there would be for an employee's departure. Unless someone deliberately builds an equivalent process for external access, it tends to fall through every gap those internal processes were built to close.
The specific, recurring failure is access that outlives the engagement: the vendor's project finishes, but nothing internal fires to revoke what they were given, because the revocation depended on an offboarding trigger that only applies to employees.
Time-bounding as the default, not the exception
Vendor access managed well starts from an explicit, known end date rather than an open-ended grant that has to be remembered and manually revoked later. Tying access to a contract's term, checked automatically rather than tracked in someone's memory, converts a process that depends on someone remembering into one that fails safe by default when nobody does.