Why You Must Re-Approve Access Every 90 Days

TL;DR — Re-approving access every 90 days is usually a security control for time-limited access reviews or expiring grants, not a bug. The main reason is simple: people change roles, projects end, devices are lost, and old permissions become risky if nobody re-checks them; the most likely fix is to ask your admin or provider whether the 90-day rule is driven by compliance, privileged access policy, or an app-specific session/consent setting. Reading time: ~7 min

What it is and where it sits

When you have to re-approve access every 90 days, you are usually interacting with one of three things:

1. An access review policy — a scheduled check where someone confirms you still need access.
2. An expiring access grant — your permission is intentionally temporary and must be renewed.
3. A consent refresh — you previously approved an app to access your account or data, and that approval expires.

All three are versions of the same idea: access should not live forever unless someone is actively responsible for it.

In a typical setup, this sits in the identity layer — the part of the system that handles sign-in, permissions, and app approvals. That identity layer often talks to:

• your company directory (a user list, such as an employee account system)
• the application you are trying to use
• a policy engine (rules about who can access what)
• an audit log (a history of approvals, denials, and changes)

What it replaces is the older habit of granting access once and forgetting about it. In older systems, a person might be added to a group in January and still have access years later, even after changing jobs.

A simplified request flow looks like this:

[You sign in]
      |
      v
[Identity provider / SSO]
      |
      +--> checks session
      |
      +--> checks group/role membership
      |
      +--> checks whether approval or grant is expired
      |
      v
[Policy decision: allow, deny, or require re-approval]
      |
      v
[Application or data]
      |
      v
[Audit log records the result]

If the 90-day timer has expired, the system does not necessarily think you are unsafe. It is saying: "This permission is old enough that we need a fresh human decision."

Why 90 days specifically?

Ninety days is common because it is frequent enough to catch stale access but not so frequent that every week becomes an approval exercise. It also lines up with many internal control cycles used for:

• contractor access
• admin access
• customer support access to sensitive data
• regulated environments where periodic review is expected

The exact number is a policy choice, not a law of nature. Some teams use 30 days for admin access, 90 days for elevated access, and 180 or 365 days for lower-risk systems.

How it actually works

Let’s walk through one realistic example: you are a customer contact who can view billing exports and support logs in a client portal, and every 90 days the portal asks you to re-approve your access.

End-to-end example

1. Day 0: your access is granted

   • An admin gives you the role billing-viewer in the portal.
   • The identity system stores:
     • your user ID
     • the role name
     • who approved it
     • when it expires or when it must be reviewed

2. You use the portal normally

   • You sign in through single sign-on (SSO, one login used across apps) or with an email/password.
   • The portal asks the identity system, "Does this person have billing-viewer right now?"
   • The identity system answers "yes" because the role is still active and within its review window.

3. The 90-day deadline approaches

   • A scheduled job runs daily or hourly in the identity system.
   • It finds grants that are about to expire or require review.
   • Depending on the setup, it may:
     • email you
     • email your manager or account owner
     • show a banner in the app
     • temporarily block access until reviewed

4. Day 90: the grant is no longer considered current

   • You click into the portal.
   • The portal checks your role.
   • The identity system sees review_due_at < now() or expires_at < now().
   • Instead of returning "allow," it returns something like "approval required."

5. Re-approval happens

   • You or your approver confirms the access is still needed.
   • The system writes a new review record to the audit log.
   • The next review date is set, often another 90 days out.

6. Access resumes

   • The next time the portal checks your role, it gets "allow."
   • Nothing about your password changed; the permission state changed.

What the system is protecting against

This mechanism is mainly trying to reduce stale access — permissions that remain after the business need is gone. Common examples:

• a contractor finished work 2 months ago
• a finance user moved to marketing but still has billing exports
• a shared mailbox was approved once and forgotten
• an app integration still has permission to read data no one meant it to keep reading

In other words, the 90-day re-approval is less about distrusting you personally and more about distrusting old decisions.

When to use it (and when not to)

A 90-day re-approval policy is useful when the cost of stale access is higher than the annoyance of re-approving it.

You probably don’t need this if...

• the system contains low-value information only
• access is already tightly limited by project membership that updates automatically from HR or your directory
• the user base is tiny and manually managed by one responsible owner
• the friction is causing people to share accounts or bypass the process

That last point matters. A weaker control that people actually follow is often better than a stronger control that causes unsafe workarounds.

Trade-offs

Every security benefit here has a cost.

The practical costs people feel most

• Interruptions: you are blocked at the moment you need the system.
• Dependency on approvers: if the approver is on vacation, work stops.
• Policy mismatch: a 90-day rule may be sensible for admin access but excessive for routine customer portal access.
• Vendor lock-in: if your provider built this deeply into their identity workflow, changing it may require product or contract changes, not just a toggle.

In practice

Below are two concrete examples you can adapt today: one for a customer/admin conversation, and one for a technical team implementing the policy.

Example 1: Ask your provider or admin the right question

If you are a customer and want the fastest path to clarity, send a message like this through the support portal or your shared admin contact.

Subject: 90-day access re-approval clarification

Hi team,

We are being asked to re-approve access every 90 days for [system/app name].
Can you confirm which of these is driving it?

1. periodic access review
2. expiring role/permission grant
3. third-party app consent expiration
4. session timeout or sign-in policy

Please also confirm:
- who the approver is
- whether the 90-day period is fixed or configurable
- whether this applies to all users or only elevated/sensitive access
- what audit/compliance requirement this supports, if any

Thanks.

This does two things: it separates access review from sign-in/session issues, and it asks whether the policy is universal or only for sensitive roles. The gotcha is that many teams casually call all of these "reauthentication," even when the real issue is permission expiry, not login expiry.

Example 2: A simple database model for expiring grants

For teams building a portal, a common pattern is to store grants with an expiry or next-review date.

create table access_grants (
  id bigserial primary key,
  user_id bigint not null,
  resource_name text not null,
  role_name text not null,
  approved_by bigint not null,
  approved_at timestamptz not null default now(),
  review_due_at timestamptz not null,
  revoked_at timestamptz,
  unique (user_id, resource_name, role_name, revoked_at)
);

create index idx_access_grants_active
  on access_grants (user_id, resource_name, role_name, review_due_at)
  where revoked_at is null;

This stores who approved access and when the next review is due. The gotcha is the uniqueness rule: if you want to allow a grant to be revoked and later re-added, you need to design the unique constraint carefully so old revoked rows do not block new active ones.

Example 3: Policy check in application code

A backend service can deny access when the review date has passed.

function canAccess(grant, now = new Date()) {
  if (!grant) return { allowed: false, reason: "no_grant" };
  if (grant.revoked_at) return { allowed: false, reason: "revoked" };
  if (new Date(grant.review_due_at) <= now) {
    return { allowed: false, reason: "reapproval_required" };
  }
  return { allowed: true };
}

This is the core decision logic an app uses before returning data. The gotcha is user experience: if you only return a generic 403 error, users think the app is broken; return a specific message like "Your access needs review" and link to the approval path in your provider's dashboard or portal.

Where to look in a dashboard

If you are trying to find the setting without shell access, start in your provider’s dashboard under areas like:

• Security or Identity → Access reviews
• Users or Directory → Roles / Group memberships
• Applications → Permissions / Consent
• Authentication → Session policies
• Audit logs → Access changes

Vendor menus vary, but these are the common places. If you see a setting about session duration, that controls how long you stay signed in; it is not the same thing as a 90-day access review.

Further reading

• NIST SP 800-63 Digital Identity Guidelines
• OWASP Authorization Cheat Sheet
• NIST SP 800-53 Access Control family
• The "Authentication" and "Authorization" sections of the MDN Web Docs
• Google BeyondCorp papers

This article was written by an AI system and published pending human review. Verify anything you intend to act on.