Access should end on the contract or internship end date, with the expiry set when access is granted, not remembered later. Cap token lifetimes below that date, review at the midpoint, and treat any extension as a new approval. Open ended access for short term people is the common failure.
Why short term people need different handling
Interns and contractors arrive in groups, work on a defined scope, and leave on a known date. That predictability is an advantage. You know in advance when access should stop, so you can build the stop into the grant.
The risk is the opposite. Nobody owns them after the start, their manager changes, the end date slips by a week, and the account lives on for months.
Set the end date at grant
- Record the end date in your identity provider. Many providers support an account expiry or a scheduled deactivation.
- Put the same date in the access ticket. The approver sees both what and until when.
- Give group membership with expiry where your tooling supports it, or schedule a removal task.
- Make extensions a new ticket with a reason. A manager's chat message is not an extension.
Cap tokens below the end date
Personal tokens outlast accounts if you let them. GitHub's organization token policy lets owners cap maximum lifetime, with separate settings for fine-grained and classic tokens. The documentation says fine-grained tokens default to a 366 day maximum, and classic tokens have no expiry requirement by default. Tokens beyond the limit are blocked from the organization but not revoked.
For a three month internship, a 366 day default is far too long. Set the cap to something you can defend, require approval for fine-grained tokens, and restrict classic tokens unless needed.
Scope matters as much as time
| Dimension | Starting point for short term people |
|---|---|
| Repositories | Only the project they work on, at Write |
| Environments | Development and sandbox |
| Data | Synthetic or masked |
| Secrets | None shared, scoped credentials if needed |
| Devices | Company managed where possible, or a remote dev environment |
| Admin roles | None |
Midpoint review
At half time, ask the supervisor to confirm the person still needs what they hold. Contractors often finish a phase early and keep phase two access they never used.
The last week
- Confirm the handover document exists.
- Collect equipment.
- Schedule the deactivation for the end of the final day.
- Rotate anything shared they could read.
- Keep a record of the date access ended.
If they might return
Interns who return next summer should be offboarded cleanly and onboarded again. Reusing a dormant account skips review and keeps stale permissions. GitHub keeps removed member data for three months, so a quick re-invite can restore old state. Decide deliberately whether you want that.
Quick check
Can I just remember to remove access on the last day?
Memory fails. Set the expiry when you grant access and add a ticket as a backstop.
What is a good token lifetime for an intern?
Shorter than the engagement. Pick a figure your team can enforce, and require approval.
Safeguard's policies and compliance evidence automation can help you show that expiry and review steps happen. A free scan is available at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Setting a personal access token policy for your organization
- GitHub Docs: Removing a member from your organization
Last reviewed: 19 October 2026.
