Smart Recertification

Smart Recertification enhances the standard recertification process with AI-powered pre-analysis that enriches each audit item with usage signals and generates recommendations, significantly reducing the time reviewers spend on obvious decisions.

Why Smart Recertification?

Standard recertification treats every item equally — a reviewer must manually inspect each user–product grant and decide whether to approve or reject. This leads to rubber-stamping, where reviewers approve everything because identifying exceptions is too tedious.

Smart Recertification pre-analyzes the user list and flags obvious cases:

• Departed users still holding access
• Role changes since the grant was issued
• Inactive users who haven't accessed the product in months
• Active users with matching roles who clearly still need access

How It Works

When a recertification cycle is populated, the smart analysis engine runs automatically:

1. Signal collection — The engine gathers data about each user: active status, last access date, current role, days since grant
2. Rule evaluation — Configurable rules determine a recommendation for each item
3. Enrichment — Each audit item is annotated with signals and a recommendation
4. Prioritization — The review queue is sorted so flagged items appear first

Signal Types

Each audit item is enriched with the following signals:

Signal	Description
user_active	Whether the user's account is currently active
last_accessed_at	Last time the user accessed this product
days_since_grant	How long the user has held this access
role_changed	Whether the user's role has changed since the grant
role_at_grant	The user's role when access was originally granted

Recommendations

Based on the signals, each item receives a recommendation:

Recommendation	Trigger	Confidence
Revoke	User departed (account deactivated)	High
Revoke	Inactive for > N days (configurable)	Medium–High
Revoke	Role mismatch since grant	Medium
Approve	Recently active with matching role	High
Uncertain	Signals are mixed or insufficient	—

Reviewer Experience

Prioritized Queue

The review queue is sorted by urgency:

1. Flagged for revocation — Items the system recommends revoking
2. Uncertain — Items that need human judgment
3. Recommended for approval — Items the system is confident about

Bulk Actions

After reviewing the recommendations, you can:

• Accept all recommendations — Apply all approve and revoke recommendations at the configured confidence level
• Filter by recommendation — View only revocations, only uncertain items, or only approvals
• Override any recommendation — Click on any item to make a different decision

Summary Statistics

The cycle detail page shows a summary:

"12 auto-revoked, 5 flagged for review, 83 recommended for approval"

Auto-Revocation Rules

Space administrators can configure rules that define how the system handles obvious cases:

Departed User Handling

Setting	Behavior
Always on	Departed users are automatically revoked
Require confirmation	Departed users are flagged but require reviewer approval
Off	No special handling

Inactivity Threshold

Configure the number of days of inactivity before a user is flagged. Default: 180 days. Can be adjusted per space.

Role Mismatch Handling

Role mismatches are always flagged for review — they are never auto-revoked, since a role change doesn't necessarily mean access is no longer needed.

Grace Period

Auto-revoked users can appeal within a configurable grace period (default: 30 days). During this window, the revocation can be reversed.

Exclusion List

Administrators can maintain an exclusion list of users who should be excluded from recertification review:

• Service accounts that always need access
• Shared credentials managed outside the normal lifecycle
• System users with permanent access requirements

Excluded users are skipped during cycle population and won't appear in the review queue.

Auto-Revoke on User Deactivation

When a user is deactivated — via SCIM provisioning, admin panel, or API — all their active access grants are immediately revoked. This happens outside the recertification cycle for real-time security:

1. User deactivated
2. All active ProductAccess grants revoked
3. Audit trail entries created for each revocation
4. Webhook events dispatched to affected spaces
5. Notification sent to the user's manager