Access certification, also called an access review or attestation, is a recurring check in which a responsible person confirms that each account and privilege is still needed, and removes what is not. It exists because access accumulates as people change roles. NIST SP 800-53 supports it through account reviews and privilege reviews.
Which standard controls point to it?
NIST SP 800-53 Rev. 5 does not use the phrase access certification, but three controls cover the activity:
- AC-2, Account Management. Among its parts: assign account managers, specify authorized users, group and role membership and privileges for each account, monitor account use, and review accounts for compliance with account management requirements at a frequency the organization sets. It also asks you to align account management with termination and transfer processes and to notify account managers when users leave or move.
- AC-2(3), Disable Accounts. Disable accounts that have expired, are no longer associated with a user, violate policy or have been inactive for a defined period.
- AC-6(7), Review of User Privileges. Review privileges at a defined frequency to validate the need for them, then reassign or remove privileges to reflect current mission and business needs.
AC-5, Separation of Duties, is the related check that no single person holds a combination of access that should be split.
The control text leaves frequency and scope as organization-defined parameters. You choose them, and an assessor will look at whether you followed what you chose.
What does a good review contain?
A review has a scope (which systems and populations), a reviewer for each item, the evidence they see, a decision per entitlement, and proof that the decision was carried out. The last part is where reviews fail: a spreadsheet marked "approved" proves nothing if the removals never happened.
Three kinds of review are common. A manager review asks whether a person's team members still need their access. An application owner review asks whether the current users of a system should have it. A privileged access review focuses on administrators, shared accounts and anything that can change security settings, and usually runs more often.
Why do reviews turn into rubber stamping?
- The reviewer cannot tell what an entitlement means. A group called "APP-FIN-RW-3" tells a manager nothing.
- The list is too long, so reviewers approve all.
- There is no default consequence. If nothing happens when a reviewer ignores the request, many will.
- The review covers people but not service accounts, API keys, tokens and AI agents, which often have the widest access and no manager.
- Leavers and movers are handled in the review instead of at the time they leave, so access lingers for months.
A constructed example
A 300-person company runs a quarterly review of its code hosting and cloud accounts. The export lists 410 accounts for 300 employees. The extra 110 break down into 60 service accounts, 30 former contractors and 20 duplicates. Managers review the 300 employee accounts, shown with plain-language role names. The 30 contractors are disabled outright under the inactive-account rule. The 60 service accounts get a named owner each, or they are retired. Two administrators hold both the right to approve a payment and to change the approval rules, which breaks separation of duties, so one role is moved. Finally, security checks the next export to confirm every removal happened.
How to check or apply this
- Define scope and frequency in writing: which systems, which accounts, how often, with privileged access more often than ordinary access.
- Pull entitlements from the source system, not from memory, and translate technical group names into plain descriptions.
- Assign each item a named reviewer and a due date, and decide the default if they do not respond. Revoking by default works better than approving by default.
- Include non-human identities: service accounts, keys, tokens, bots and agents. Every one needs an owner and a purpose.
- Record decisions and then verify that removals took place, by comparing a fresh export to the decisions.
- Connect the review to the joiner, mover and leaver process so most changes are handled when they happen.
- Track measures such as time to remove access after termination and the share of reviews completed on time.
Safeguard's agent identity and asset discovery features help with step 4 on the software side, by showing which agents and services exist and what they can reach. They do not replace an identity governance system, and they do not certify that your review meets any framework.
Quick check
How often should access be certified?
NIST SP 800-53 leaves frequency to the organization. Choose one based on risk, review privileged access more often, and follow what you wrote down.
Do service accounts need to be in the review?
Yes. They often have broad access and no manager. Give each an owner and a purpose, or retire it.
Sources
Last reviewed: 18 October 2026.
