Skip to content
LearnAccess review

What is an access review?

Also known asaccess recertificationuser access review
Example. Kiteline is a fictional company.
On this page

An access review is a scheduled check in which an owner of a system goes through who and what has access to it, person by person and machine by machine, and confirms or removes each grant based on whether it is still needed for the job.

Why it is needed

Access grows by default and shrinks only on purpose. People change teams and keep their old permissions. A contractor's access outlives the contract. A pipeline gets production access for one migration and keeps it. None of this is a breach; it is drift, and it widens what any one compromise can reach.

Reviews are also a standard control. NIST SP 800-53 asks organizations to "review accounts for compliance with account management requirements" at a frequency they define, and to align account management with "personnel termination and transfer processes" (NIST SP 800-53 Rev. 5, AC-2).

What to review for secrets

  • People per environment. Who can read production? Who can edit it? Does each still need it?
  • Groups and profiles. Group membership is where access hides. Check what each group grants, then who is in it.
  • Machines and tokens. Each server and pipeline credential: what it reads, whether it is still used, when it expires.
  • Outstanding links and invitations. Anything that grants access to someone without an account.
  • Admin rights. The few accounts that can grant access to everything deserve the closest look.

Making it work

  • Review by the owner of the resource, not by a central team that can't judge need.
  • Default to remove. If nobody can say why a grant exists, take it away; it can be requested again.
  • Keep it small and frequent. A quarterly review of production access is more likely to happen than an annual review of everything.
  • Record the outcome. What was checked, what was removed, by whom.

Common mistakes

  • Rubber-stamping. Approving every line because the list is long. Shorter lists, grouped by role, help.
  • Reviewing permissions but not credentials. A removed permission doesn't revoke a token that is still valid.
  • Forgetting the moves. Transfers between teams are where excess access builds up fastest.

How Crunu supports a review

Crunu has no built-in review campaign or reminder, and access granted to people has no expiry date, so the schedule is yours. What Crunu gives you is a clear picture to review:

  • Access per environment. Each environment's access list shows who holds Editor, Reader, Specific files or Operator, directly or through an access profile. Changing a profile changes access for everyone in it, and each version of a profile is signed.
  • Machines and service tokens with their environments, leases and usage limits.
  • Organization status: machines online and offline, certificates near expiry, open alerts.
  • The audit log, filterable by person, action, environment and period, for evidence of what changed.
Example. Kiteline is a fictional company.

When a review takes someone out of an environment where they had the key, Crunu marks that environment as needing rotation, and Pending actions tracks it until a key holder rotates it. Removing someone from the organization rotates the keys as part of the removal and produces the exposure report of what they received. For departures specifically, see what to rotate when a developer leaves.

Sources

From the blog

  • AI agents

    API keys in MCP server configs: where they end up

    MCP clients keep server settings as plain JSON, and the API key usually sits in it. Where those files live, who can read them and how to keep keys out.

    AI coding agents guide

  • AI agents

    Prompt injection meets your environment variables

    A coding agent with a shell can print its environment, and text it reads can ask it to. How to make the keys within its reach worth little.

    AI coding agents guide

  • Security

    One key per environment: why dev must not open prod

    Server-side vaults separate dev and prod with permissions the server enforces. Why the boundary is stronger when each environment has its own encryption key.

    Sharing .env files guide