Guide
Giving a contractor access that expires on its own
Also searched as temporary contractor access, time-limited access, and third-party or vendor access management.
This is the one case where the end date is known before the access starts. It is also, reliably, one of the cases where access outlives the engagement.
Access that expires automatically is access granted with an end timestamp recorded at the moment it starts, removed by a process that runs without anyone remembering to trigger it. A calendar reminder is not this. A ticket in a backlog is not this. Both depend on a person, and the person is the part that fails.
The contractor case is worth writing about specifically because it is the easiest one to get right and it usually is not. Almost everything hard about time-bound access — guessing the duration, judging whether the task is finished — is absent here. You have a statement of work with a date on it. The information is sitting there, and it still does not reach the systems that hold the access.
Why the usual approaches fail
The calendar reminder
Someone sets one for the last day of the engagement. It fires while they are on holiday, or after they have changed teams, or during an incident. It is also a reminder to do work rather than the work itself, so it competes with everything else in the day, and "revoke access for someone who left three weeks ago" competes badly.
The offboarding checklist
Better, and it fails differently: it runs when someone notices the engagement ended. Contractors rarely have a leaving date that anybody announces. The work tapers, the final invoice arrives some weeks later, and the access sits between those two events with nobody assigned to notice.
The disabled identity
Disabling the account in the identity provider is genuinely good and genuinely partial. It stops interactive sign-in. It does not necessarily revoke a personal access token they created in GitHub, an access key issued in AWS, a webhook they configured, or membership of a group that grants access to a system federated somewhere else. It also does nothing about the account being re-enabled for the next engagement with every permission from the last one intact — which is how a six-week contractor accumulates a staff engineer's access over three years.
A contractor is almost never in one system. A typical engagement touches a GitHub organization, an AWS account, a Google Workspace group and an internal application behind Entra ID or Okta. Four grants, made on four days, by three people, in four places with four different removal procedures. Offboarding gets three of them. It is nearly always the fourth that turns up in an audit, and which one is the fourth varies each time, so no checklist converges.
What "expires automatically" actually requires
- The end date recorded at grant time. Not stored in a ticket, not in someone's head — attached to the access itself, in a system that will act on it.
- One expiry covering every system. If each system tracks its own window, you have four things to get right instead of one, and the failure is partial rather than total, which makes it harder to spot.
- Removal that runs unattended. No approval to revoke, no queue that can stall, and nothing that can block it — a quota, a license state, an unpaid invoice. A blocked grant produces a complaint in minutes; a blocked removal produces silence.
- A record of the removal, not just the grant. "Who had access to what, and when did it stop" needs both halves. A log of grants proves you were careful about giving access and nothing about taking it back.
- Re-granting that starts from zero. The next engagement should be a fresh grant with its own end date, not the reactivation of an account carrying everything the last one accumulated.
A duration worth defaulting to
The instinct is to match the engagement — six months of access for a six-month contract. In practice a shorter window that renews is better on every axis except convenience, and the convenience cost is smaller than it sounds because renewal is one click by someone who already knows the answer.
It also converts a silent failure into a loud one. If the contractor still needs access and it lapses, you find out immediately and cheaply. If they no longer need it, nothing happens and it disappears on its own. The six-month grant has the opposite property: it is correct right up until it is quietly wrong, and nothing tells you when that changed.
How TemprBac approaches it
TemprBac grants access as a time-bound package: a named bundle of groups across the systems you already run — Entra ID, Okta, GitHub, Google Workspace, AWS IAM and Active Directory — requested by the person who needs it, approved if the package requires it, and revoked automatically when the window closes. One package, one expiry, every system it covers, so the four-grants-three-removals problem does not arise.
Groups and roles are the primitive because every system worth governing expresses access that way and exposes it over an API, which is what lets a single expiry reach an AWS account and a GitHub organization that share no directory. Removals are recorded next to the grants, so "who had access to what, and when did it stop" is a query rather than an investigation.
And one rule shapes the product: nothing may block revocation. No plan limit, no quota, no billing state stops access from expiring, because a cap that could stop revocation would turn every temporary grant into a permanent one — which is the exact failure this page is about. Pricing covers what the limits do affect.