Access certification is the formal act of confirming that the access people hold is still the access they should hold. A reviewer signs off entitlement by entitlement, and anything they reject is removed. It is the same control as a user access review, seen from the compliance side, where the emphasis lands on the sign-off and the paper trail rather than on the looking.
If there is a distinction between the two terms it is one of emphasis. Certification stresses the attestation, the formal statement that the access is correct, while review stresses the examination. Auditors and legacy IGA vendors tend to say certification, practitioners tend to say review, and both are describing the same thing.
campaign model
Q1 |------------------------------------------------|######| 6,000 entitlements, 10 days
Q2 |------------------------------------------------|######| bulk approvals in the last 2 days
continuous model
|#| |#| |#| |#| |#| |#| |#| |#| |#| each change reviewed as it happens;
the quarterly run shrinks to exceptionsWhat is a certification campaign?
Certification has traditionally been run as campaigns, and a campaign is a scheduled batch with five parts.
- A scope: a set of applications, a department, a framework's in-scope systems or a class of entitlements.
- A population: every account and entitlement inside the scope, pulled at the moment the campaign opens.
- A routing rule: each item goes to the person's manager, the application owner, or both.
- A deadline: the date by which every item must carry a decision.
- A report: completion, decisions and revocations, produced when the campaign closes.
A practitioner in a regulated industry described where campaigns sit among the other controls an IAM platform has to provide:

Certification - the ability to do periodic access reviews of users. This is typically run yearly or quarterly and you would be asking the user's manager and possibly the application owner to review.
Why the batch model fails
Batching a quarter's worth of access into a single deadline creates a wall of work that arrives all at once. Reviewers facing hundreds of unfamiliar entitlements with a Friday deadline do the rational thing and approve in bulk. The campaign completes, the evidence is generated, and the actual access barely changes. It is efficient to administer and hollow in effect.
What does certification cover when apps have no SCIM?
Only the accounts that get pulled into scope, which is fewer than it sounds.
What enters the population
SCIM-connected applications hand the identity provider a complete account list, so the campaign population for those applications is a query. Applications without SCIM do not. Their accounts enter the campaign only if someone exports them by hand, and an export covers the applications the person building the campaign remembered. Local accounts created inside a product, invitations sent by a colleague and logins that predate the identity provider are all absent from the identity provider's view and present in the application's own.
Where the revocations run
A decision is only half of certification, because the other half is the change it produces inside the application. For a SCIM-connected application the rejection travels back through the directory and the account changes state. For everything else the rejection is a line in a report, and someone has to open the application and act on it, usually days later and often never. That second gap is invisible in the campaign report, because the report records the decision rather than its effect.
| Application | In the campaign population? | Revocation path |
|---|---|---|
| SCIM on the current plan | Yes, from the identity provider | Automatic, through the directory |
| SSO without SCIM | Only if exported by hand | Manual, inside the application |
| No SSO | Only if someone remembers the application exists | Manual, inside the application |
A campaign scoped to the SCIM applications certifies the accounts that were already in sync and leaves the rest of the stack unexamined. The accounts that fail audits live in the second and third rows.
What is continuous certification?
The alternative is to stop batching the work into quarters. Continuous certification evaluates access as it changes, so that a new grant, an unusual entitlement or a role change that adds permissions is reviewed close to when it happens.
What triggers a review
Three events carry enough signal to be worth routing on their own. A grant outside the birthright bundle for the role, because someone asked for something the job does not include by default. A role change that adds permissions without removing the previous set, which is the mover case that campaigns are meant to catch a quarter later. And an account that has gone unused past a threshold, which is the cheapest revocation available because nobody will notice it going.
| Campaign certification | Continuous certification | |
|---|---|---|
| When access is reviewed | Once a quarter, all of it | When it changes, plus a smaller scheduled run |
| Reviewer load | A wall of rows against a deadline | A few items a week, with context |
| Time between a bad grant and its review | Up to a quarter | Days |
| Scheduled campaign scope | The whole population | The exceptions the continuous flow did not cover |
| Evidence | A report per campaign | A running record plus the campaign report |
What the scheduled run becomes
The heavy quarterly campaign shrinks, because most access has already been confirmed in the flow of work. What remains for the scheduled run is the exceptions, not the entire population: the entitlements no trigger fired on, the applications with no event stream, and the accounts whose owner changed since the last pass. A campaign of that size can be read rather than approved.
What it changes for evidence
The benefit is not only lighter campaigns. Access stays current in between them, instead of drifting for three months and being corrected in a rush. The evidence changes shape as well as the timing. A campaign produces a document per quarter, so the interval between two documents is unexamined by construction. A continuous record has no interval, which is the difference between showing that access was correct on four days of the year and showing that it was correct throughout.
Iden runs certification as campaigns scoped by application, framework or population, with the SOC 2 or ISO control the campaign satisfies attached to it. Between campaigns, changes in access are flagged as they happen, so the scheduled run shrinks to what changed. Approve and revoke sit on every row, and a revoke is executed in the application the moment it is clicked. The feature behind it is Access reviews with a decision on every row.

Ein SOC-2-Review für eine Applikation. Zwei Zeilen sind markiert, weil die Person im HR-System inaktiv ist und den Zugriff noch hat. Drei der Zeilen sind keine Personen.
What does a certification have to prove?
The evidence bar is the same as for any review, and it has five parts.
- Scope: what was covered, and by implication what was not.
- Reviewers: who signed off, and whether they had the standing and the context to.
- Decisions: the keep-or-remove call recorded per item, with a timestamp.
- Timing: when the certification opened and closed, against the schedule the policy commits to.
- Enforcement: proof that the rejected access was actually revoked, taken from the system where it lived.
Where certifications fall short
The fifth is where certifications most often fall short. A campaign can produce a complete set of decisions and still leave the rejected access in place, because nobody wired the removal to the sign-off. The certification then says one thing while the system says another, and the discrepancy is trivial for an auditor to find, because finding it takes one query in the application rather than a judgement about the review's quality.
A real certification closes that loop. The sign-off drives the revocation, and the evidence records actions taken rather than intentions logged.