Access Certification Reviews That Aren't Rubber Stamps

Access certification is often the most hated process in identity governance. Managers receive an email containing a spreadsheet of user names and permissions, asked to click "Approve" or "Revoke." Most managers do not remember every permission their direct reports hold. Consequently, they click "Approve" for everyone. This is the "rubber stamp" problem, a form of rubber stamping that creates a false sense of security while allowing privilege creep to accumulate unchecked.

The root cause is not manager negligence; it is a flawed mechanism. The current model relies on human memory to verify technical state. This is cognitively impossible at scale. To fix this, we must shift from subjective attestation to evidence-based verification.

Why Manager Memory Fails

In a typical enterprise, an access review might involve a mid-level manager overseeing 10–20 engineers. Each engineer may have access to five to ten systems, ranging from GitHub repositories to production databases. That is 50–200 distinct access decisions per review cycle. No human can reliably recall the precise scope of access for each individual over a six-month period.

When a manager clicks "Approve," they are not verifying access during an access review; they are signing a document that says, "I haven't heard any complaints about this person's access." This is not security. This is administrative convenience.

NIST SP 800-53 controls for Access Control (AC-2) require that organizations review accounts periodically. However, the standard does not mandate how the review happens. Most organizations interpret this as a checkbox exercise, leading to rubber stamping and an audit trail that proves nothing about actual security posture.

The Evidence-Based Model

To eliminate rubber stamping, the review interface must change. Instead of asking "Do you approve this access?", the system should present "Here is what this user did with this access."

This is the core mechanism of an entitlement review: the system aggregates usage data and presents it alongside the entitlement. The manager’s decision is then based on observable behavior, not memory.

What Constitutes Evidence?

Evidence is any log or metric that proves the utility or absence of an access right. Common sources of usage evidence include:

1. Authentication Logs: When did the user last log in? If a developer has access to the production database but hasn’t logged in for 90 days, the access is likely stale.
2. Application Activity: Did the user create, read, update, or delete (CRUD) data? For an entitlement review, a user with "Admin" rights who only performs "Read" operations may have excessive privileges.
3. Ticketing Systems: Was the access granted via a Jira ticket for a specific project? If the project ended three months ago, the access should be reviewed.
4. Privilege Escalation Events: Did the user use sudo or elevated roles? High-frequency elevation suggests the user needs permanent elevated access, not just temporary justification.

A Concrete Workflow

Let’s walk through a specific scenario. Sarah is a security engineer. She has configured an access certification campaign for the "Production Database" role. The system identifies 50 users with this role.

Step 1: Data Aggregation

The identity governance platform queries the following sources:

• IAM System: List of 50 users with "Production DB Admin" role.
• Database Audit Logs: Last active timestamp for each user.
• Jira API: Open tickets assigned to each user that reference the production database.

The system generates a report. It does not just list names. It structures the data like this:

User	Role	Last Activity	Open Tickets	Risk Score
Alice	Prod DB Admin	2 hours ago	3 (Active)	Low
Bob	Prod DB Admin	120 days ago	0	High
Carol	Prod DB Admin	5 days ago	1 (Closed)	Medium

Step 2: Manager Review

Sarah’s manager, Dave, receives a notification. He logs into the certification portal. He sees a list of his direct reports.

For Alice, the interface shows: "Last activity: 2 hours ago. 3 active tickets." Dave recognizes Alice. He clicks "Retain."

For Bob, the interface shows: "Last activity: 120 days ago. No active tickets." Dave does not recognize Bob. The system flags Bob as "High Risk" due to inactivity. Dave clicks "Revoke." He does not need to remember Bob’s role. The evidence tells him Bob is not using the access.

For Carol, the interface shows: "Last activity: 5 days ago. 1 closed ticket." Dave checks the ticket. It was for a one-time migration. He clicks "Revoke."

This workflow takes minutes per user. It reduces cognitive load. It produces a defensible audit trail: "Access was revoked because there was no recent activity and no active business justification."

Risk-Based Sampling

Not all access requires full review. Reviewing every single permission for every user is still expensive. A more efficient approach is risk-based sampling.

The system assigns a quantitative risk score to each entitlement based on:

• Sensitivity of the Resource: Production database > Dev sandbox.
• Privilege Level: Admin > Read-only.
• User Role: Engineer > Intern.
• Anomaly Detection: Does this user’s behavior deviate from their peers?

This quantitative score determines auto-certification thresholds. High-risk entitlements trigger mandatory reviews. Low-risk entitlements (e.g., read-only access to a public wiki) can be auto-certified or reviewed less frequently. This focuses human attention where the security impact is highest, distinct from the qualitative risk labels used in the concrete workflow above to aid human decision-making.

Implementation Challenges

Implementing evidence-based certification is critical for security compliance and requires integration. You need APIs to pull data from your IAM, database, and ticketing systems. You need a dashboard to present this data clearly.

Most identity governance and Administration (IGA) tools support this, but it requires configuration. You must define what counts as "active" usage. For some systems, a login is enough. For others, a specific query execution is required.

Start small. Pick one high-risk application. Integrate its logs. Build the evidence report. Test it with one team. Iterate.

Conclusion

Rubber stamping is not a cultural problem. It is a design problem. When you ask humans to perform tasks that exceed their cognitive capacity, they will find shortcuts. By providing evidence, you remove the need for memory. You replace guesswork with data.

The goal of access certification is not to generate paperwork. It is to ensure that only the right people have the right access. Evidence-based reviews make this possible. They turn a compliance chore into a security control.

Stop asking managers to remember. Start showing them what their users did.