Access recertification is the recurring proof that the right people still have the right access. Most organisations start with spreadsheets, screenshots and quarterly reminders. That works at fifty users and collapses at five thousand, because the evidence is manual, the reviewers are guessing and the audit trail is a folder. Automation changes the economics — if you model the problem correctly.
Why recertification breaks at scale
The result is a process that looks complete and proves very little. Auditors notice.
- Entitlements are spread across directories, applications, databases and servers.
- Reviewers are asked to approve access they cannot see or explain.
- Evidence is collected after the fact, usually by screenshot.
- Review fatigue turns approval into a rubber stamp.
- Non-SSO systems are excluded because they are hard.
What a reviewer actually needs
A reviewer does not need a list of every permission. They need enough context to make a defensible decision. In practice that is five things:
- Who has access.
- To what, in business terms.
- Why they have it — role, project or request.
- When they last used it.
- What the risk is if it is wrong.
The automation loop
The loop matters more than any single tool. If collection is incomplete or decisions are not attributable, the rest of the automation only produces faster bad evidence.
- Collect entitlements from every identity source, including directories, databases and operating systems.
- Normalise them into a common model: principal, resource, permission, source and last-used evidence.
- Assign each entitlement to a reviewer based on ownership, not org-chart convenience.
- Capture a decision — retain, revoke or escalate — with a reason.
- Produce evidence: who reviewed what, when, and what changed.
Covering Bastion, databases and OS accounts
SSO covers applications, not infrastructure. Production access often runs through a jump host, with database and operating-system accounts that never appear in the identity provider. These are usually the highest-risk entitlements and the ones most often excluded.
Collect them through the same boundary operators already use. A scheduled job inside the environment can enumerate accounts and group membership, then deliver signed output outbound. The goal is coverage without weakening the access boundary.
Evidence that survives an audit
This is the same chain-of-custody logic used for audit evidence collection, applied to access decisions.
- Attributable: a named reviewer made a specific decision.
- Reproducible: the same collection can be re-run and compared.
- Complete: the scope is stated, including exclusions.
- Tamper-evident: output is hashed and time-stamped.
- Timely: evidence reflects the review period, not the week before the audit.
Rollout order
Do not start with every system. Start with the entitlements that would matter most in an incident: production infrastructure, privileged roles, financial systems and customer data.
- Phase one: privileged and production access.
- Phase two: business applications with regulatory exposure.
- Phase three: the long tail, automated where ownership is clear.
Keep migration and recertification separate
Recertification is not a one-off migration. If you are moving identity providers at the same time, keep the two workstreams separate: migration changes where access lives; recertification proves who should still have it.
Key takeaways
- Recertification fails when reviewers lack context, not when reminders are missing.
- Collect entitlements from every source, including Bastion, databases and OS accounts.
- Every decision needs a named reviewer, a reason and a timestamp.
- Start with privileged and production access; expand once the evidence holds.
Related services
Sources
Founder & CEO
Yashwant DanielYashwant Daniel writes on compliance and trust engineering, custom software delivery and applied AI at Solvstrat — covering how regulated and mid-market teams build systems that hold up under audit, scale and scrutiny.
LinkedIn