Access decays towards permissive
Access grants are additive by default. Someone joins a project and gains rights; the project ends and nobody removes them. Over a few years this produces a workforce whose permissions describe their career history rather than their current job.
The important design insight is that the drift is structural, not cultural. Any scheme that relies on people remembering to remove access will fail. Only schemes with an expiry built in survive.
Assign to groups, never to people
Direct assignments are invisible. They do not appear when you review a group, they are not removed when someone changes team, and they accumulate in places nobody thinks to look.
Grant every permission to a group, name the group after the job rather than the permission, and make membership the only lever. "Website content editors" survives a platform migration; "Storage Blob Data Contributor – prod" does not.
Note
The test of a good group name is whether a line manager can decide membership without asking a technical question. If they cannot, the group is named after infrastructure rather than after work.
Joiners, movers and leavers
Most organisations handle joiners well, because someone is waiting to start work and complains. Leavers are handled adequately, because HR has a process. Movers — people who change role internally — are handled badly almost everywhere, and they are where privilege accumulates.
The fix is to treat a move as a leave followed by a join: remove all group memberships associated with the previous role, then add those of the new one. It feels heavy-handed and it is the only version that works.
| Event | Action | Target time |
|---|---|---|
| Joiner | Add to role groups from a role template | Before first day |
| Mover | Remove previous role groups, then add new ones | Within five working days |
| Leaver | Disable account, revoke sessions and tokens | Same day |
| Contract end | Automatic expiry, already scheduled at grant | Automatic |
Target times shown are illustrative for a demonstration site. Set your own against your contractual and regulatory obligations.
Disabling an account is not revocation
An issued token remains valid until it expires, regardless of the account's state. Where an incident requires immediate revocation, the account must be disabled and refresh tokens invalidated, and the effective delay is the access token lifetime.
Know that number before you need it. Discovering during an incident that your tokens live for eight hours is an unwelcome way to learn it.
Privileged access should be temporary
Standing administrative rights are the highest-value target in any estate. The practical alternative is elevation on request: no permanent membership of privileged groups, activation for a bounded window with a stated reason, and an approval for the most sensitive roles.
- Elevation window measured in hours, not days.
- A reason recorded at activation, reviewed afterwards.
- Multi-factor authentication required at activation, not merely at sign-in.
- Break-glass accounts excluded from the scheme, stored offline, and monitored so that any use raises an alert immediately.
Watch out
Every organisation needs break-glass accounts, and every organisation forgets to test them. An emergency account whose credential no longer works is worse than none, because it is relied upon. Test the recovery path on a schedule.
Workload identity is a separate problem
Applications and pipelines need access too, and they are frequently given a person's credential or a shared service account with an unmemorable password in a spreadsheet. Use platform-managed workload identities so there is no credential at all, and where a federated credential is used, scope it to a specific repository, branch and environment.
Review with data, not with lists
Sending a manager a list of two hundred permissions produces approval, not review. A useful access review is short, targeted and evidence-led: show the memberships that have not been used in ninety days, the assignments made outside the standard process, and the accounts with privileged rights and no recent elevation. Ask about those.
Access management done this way is a small recurring cost. Done the other way it is a large one-off cost, incurred at the worst possible moment, usually while somebody external is asking to see your logs.