> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/governance/certification.md). # Access certification Access certification in OpenIAM — the two campaign types, the preview-then-promote launch model, what reviewers see, and the evidence a campaign leaves behind. An **access certification** campaign asks named people to look at access that already exists and say, item by item, whether it is still justified — then records what they said. It exists because grants accumulate: nothing revokes access when the reason for it quietly expires, so periodically someone who knows the person, or knows the application, has to be asked. Recertification, attestation and user access review all name this same subsystem. Reviewers meet the work in SelfService, on a page headed **Certifications**. ## Two campaign types, and one filter | Type | Certifies | The reviewer sees | | ----------------------------------------------------------- | ------------------------------------------------------ | ----------------------------------------- | | **User certification** (`USER_CERTIFICATION`) | A named population of people | One user and all of that user's access | | **Application certification** (`APPLICATION_CERTIFICATION`) | Who holds the entitlements in one or more applications | One entitlement and everyone who holds it | **Risk is not a third type.** Either type can be narrowed to the access grants scoring at or above a threshold, set on the certification's **Risk** tab. A third type existed up to 2026.9.0 and was removed in 2026.9.1 — see [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md). ## Start here | If you are… | Read | | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | New to certification here | This page, then [The certification model](/administration-guide/governance/certification/certification-model.md) — the objects, the tables, and the separate database that makes campaigns reportable | | Building your first campaign | [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md), then [Preview and launch a campaign](/administration-guide/governance/certification/preview-and-launch.md) | | Deciding who reviews, and for how long | [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md) — and the two batch tasks without which no reminder is ever sent | | Watching a campaign that is already live | [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md) | | Briefing the people who will do the reviewing | [What your reviewers see](/administration-guide/governance/certification/the-reviewer-experience.md) | | Giving reviewers context beside each decision, or reading one item's audit trail | [Caddie — Access Review Assistant](/administration-guide/caddie.md) — the panel, its blocks, and the History column | | Producing evidence for an auditor | [Campaign history and evidence](/administration-guide/governance/certification/campaign-history-and-evidence.md) | | Running the service itself | [Operate certification services](/administration-guide/governance/certification/operate-certification-services.md) | | Looking at a campaign that has stopped moving | [Diagnose a stalled campaign](/administration-guide/governance/certification/diagnose-a-stalled-campaign.md) | ## The one thing that has changed most **Campaigns are launched from a preview, and only from a preview.** A preview computes the whole campaign — who is in scope, which items would be created, who would review them, and everything excluded and why — without writing to the certification database, notifying anyone, or starting a workflow. A human then promotes it. This has a consequence people miss: **a scheduled certification produces a preview and waits.** It does not open a campaign unattended. Every cadence you commit to needs a named person rostered to promote it. ## The shape of a campaign 1. **Define** a certification — type, scope, reviewer steps, expiration policy. Nothing has happened yet. 2. **Preview** it. Read the three numbers that say whether the scope is right. 3. **Launch** from the preview. Review items are created, one workflow per user starts, reviewers are mailed, and the exclusion slice is captured as evidence. 4. **Review.** Reviewers certify or revoke, in SelfService, holding decisions in a cart until they submit. 5. **Settle.** Revocations are applied when each user's review completes; whatever nobody decided is handled by the expiration policy. 6. **Close.** The campaign reaches `COMPLETED`, `EXPIRED`, `PARTIALLY_EXPIRED` or `AWAITING_SIGN_OFF`, and the result report is generated. ## Glossary | Term | Meaning | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Certification | The reusable *definition* — type, scope, reviewers, policy. One `CERTIFICATION` row. Holds no decisions | | Campaign | One *execution* of a certification. One `CAMPAIGN` row, with its own copy of the policy flags taken at launch | | Review item | One user × entitlement row to be decided. One `ACCESS_REVIEW_ITEM` row | | Preview | A computed, browsable simulation of a launch that writes nothing and notifies nobody | | Promote | Turning a completed preview into a live campaign | | Exclusion | A user or access item the scope or reviewer resolution dropped, with a recorded reason | | Reviewer step | One level of the review. Steps run in order; each has its own window and escalation chain | | Decision cart | The reviewer's unsubmitted decisions, held client-side until they submit | | Auto-certified | A grant the campaign's automation rule approved at launch, without a reviewer, because its membership risk was at or below the maximum score | | Membership risk score | The one risk filter on a certification. Inclusive: a grant at or above the number is reviewed | | Sign-off | The `AWAITING_SIGN_OFF` state a fully auto-certified campaign reaches. **No screen currently completes it** — see [Operate certification services](/administration-guide/governance/certification/operate-certification-services.md) | ## Related * [Risk management](/administration-guide/risk.md) — scoring, and [Access certification and risk](/administration-guide/risk/certification.md) for the Risk tab in full * [Caddie — Access Review Assistant](/administration-guide/caddie.md) — decision support beside each review row, and the audit trail every item carries * [Segregation of duties](/administration-guide/governance/sod.md) — the other governance subsystem * [Certification database tables](/administration-guide/reference/certification-tables.md) — every table and column * [Designing a certification programme](/solution-architecture/governance/certification-programme.md) — type, cadence, scope and reviewer as a design decision *Applies to OpenIAM 2026.9.1. Last reviewed 23 September 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/governance/certification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.