> 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/risk/certification.md).
# Access certification and risk
How a certification uses risk — the Risk tab, the membership risk threshold, the auto-certify rule, and what an auto-certified item is.
This page is for the campaign owner or compliance owner who configures certifications, and for the reviewer who wants to know what an auto-certified item is. It explains every control on a certification's **Risk** tab, exactly which grants the threshold keeps in or leaves out, and what to do with items the system approved. How the scores themselves are produced is on [Risk policies](/administration-guide/risk/policies.md).
**On this page**
* [Why risk belongs in certification](#certification-why)
* [The Risk tab](#cert-risk-tab)
* [Membership risk score](#cert-membership-threshold)
* [The band reference row](#cert-band-reference)
* [Enable Beta Features](#cert-beta-features)
* [Automation rules](#cert-automation-rules) · [Auto-certify switch](#cert-auto-certify-enabled) · [Maximum score](#cert-auto-certify-max-score) · [Reviewer visibility](#cert-auto-certify-visibility)
* [Auto-certified items](#cert-auto-certified-items)
* [What the preview shows](#cert-preview-exclusions)
* [A worked campaign](#certification-worked-example)
* [The identity risk threshold has been retired](#cert-identity-threshold)
## Why risk belongs in certification
A campaign over 50,000 grants reviewed uniformly is a campaign that gets rubber-stamped. Nobody can give 50,000 rows real attention, so every row gets the same three seconds and the dangerous ones get lost in the crowd. Risk lets you review less and review better: leave out the grants with no warning signs, approve the routine ones by rule, and put the reviewer's attention on the rows that have earned it. The campaign record then shows, for every item, why it was reviewed, skipped or approved.
## The Risk tab
Open a certification in **Webconsole → Access Certification**. The **Risk** tab is the second tab, after **Configurations**. Its page title is **Risk Configuration** and its subtitle says what it is for: *Set the membership risk threshold that decides which access reaches a reviewer, and the automation rules.*
The tab is present on every certification type, because risk does not define a scope; it **narrows** the scope the other tabs define. A campaign over the Finance department stays a campaign over Finance; the Risk tab decides which of their grants reach a reviewer this cycle.
It holds four things, in this order:
1. The **Membership risk score** filter card, with the band reference row inside it.
2. A banner restating in one sentence what the filter currently does.
3. The **Enable Beta Features** checkbox.
4. The **Automation Rules** block.
Most controls carry a small book icon that opens the matching section of this documentation.
## Membership risk score
This card is the only risk filter a certification applies. It filters **grants**, not people. It has a switch and a slider from 0 to 100. The switch ships off; turning it on sets the slider to 50, or back to the last value you chose.
The rule is inclusive, and the wording on screen is not:
* A grant whose membership risk score is **at or above** the threshold is reviewed.
* A grant **below** it is dropped from this cycle. Nobody sees it and nothing is recorded against it.
* A grant with **no score** is **kept** and sent to a reviewer, on the principle that a human should look at what the system could not score. Until risk has actually computed membership scores, the filter therefore drops nothing.
* A person whose every grant falls below the threshold has nothing left to review and is skipped.
{% hint style="warning" %}
**The card says "above" and "certified". Read it as "at or above" and "reviewed".** A grant scoring exactly the threshold is included, and being included means it goes to a reviewer, not that it is approved. The subtitle *Access grants scoring above this are certified* and the footer *Above {N} → … matches this filter* are both misleading on those two points.
{% endhint %}
The score it reads is the grant's own membership risk. That number is built on the entitlement's risk as its floor, as described under [Risk policies](/administration-guide/risk/policies.md#user-policy-aggregation), but the filter never reads an entitlement's score directly.
With the threshold at 50 and the shipped bands, Tom Becker's `Payments-Admin` at 98 is reviewed and his `Finance-Reports-Read` at 38 is not, even though a reviewer might want to see the two side by side. Set the threshold with the reviewer's judgement in mind, not only the volume.
Switched off, the card greys out, shows a **Disabled** chip and states that this score is ignored when selecting access items. The banner beneath then reads *No risk filter applies. Every access item in the configured scope enters the cycle.* Switched on, it reads *The membership risk filter applies. An access item enters the cycle when its membership scores {N} or above. Everything below is treated as acceptable and skipped.*
{% hint style="info" %}
**One case is dropped that should not be.** A grant that risk scored but could not assess is stored as a zero, and the filter cannot tell that zero apart from a genuine low score, so any threshold above 0 drops it. Everywhere else in the product an unassessed grant is routed to a human. If a campaign is smaller than you expect, this is worth checking before the threshold is.
{% endhint %}
## The band reference row
Inside the filter card, four small cards read **Low 0-49**, **Medium 50-74**, **High 75-89** and **Critical 90+**. A shield marked *In review* appears on every band whose top clears the threshold, and the band containing the threshold is highlighted.
{% hint style="danger" %}
**These ranges are fixed decoration. They are not your policy's bands.** The bands that scores actually carry come from the **Membership scoring policy**, where they ship at Medium 25, High 50 and Critical 75. A threshold of 50 reads on this row as "Medium and up" while, under the shipped policy, it is "High and up". Read your real thresholds on **Administration → Risk policies** before choosing a number here, and ignore this row until a release note says it follows the policy.
{% endhint %}
## Enable Beta Features
A checkbox, off by default. It does two things for campaigns launched from this certification: it shows the risk badges, columns and explanations to reviewers, and it unlocks the **Automation Rules** block. With it off, reviewers see no risk information and no grant is auto-certified, whatever else is set on the tab. The filter above works either way.
Checking it reveals a banner warning that beta features are still being validated and may change or be removed, and that they should be enabled only for campaigns whose reviewers are prepared to see experimental functionality.
Turning it off again switches auto-certification off and clears its settings, both on the screen and again at launch.
## Automation rules
There is exactly **one** automation rule, and it can only approve. It never revokes. It is evaluated once, at launch, for every grant that enters the campaign, and it approves a grant only when **all** of the following hold, checked in this order:
1. Auto-certification is switched on and a maximum score is set.
2. The grant has no segregation-of-duties violation, resolved or not.
3. The grant has a membership risk score. An unscored grant always goes to a reviewer.
4. The grant's band is below **High**. A High or Critical grant is never auto-certified, whatever the maximum score says. A band the system cannot read counts as being at the ceiling.
5. The grant's membership score is at or below the **Maximum score**.
Points 2 to 4 cannot be configured away. They are why the maximum score is capped one point below the policy's High threshold.
The block opens with a ceiling row naming where that cap comes from: **Ceiling from Membership scoring policy · subject class USER**, followed by **MAX 49** with the shipped policy. The ceiling is the policy's **High at** minus one, and falls back to 49 when the risk service cannot be reached.
{% hint style="info" %}
**Ignore the words "subject class USER" in that row.** Subject classes were removed when the two risk policies were merged into one. The label was left behind and means nothing; the ceiling comes from the single policy named beside it.
{% endhint %}
### Auto-certify switch
The switch at the top of the block, off by default and disabled until Enable Beta Features is on. Turning it on reveals the two fields below. Two things are then required before the certification will save: a **Maximum score** between 0 and 100, and a campaign manager on the certification. Saving without either is refused with a message naming the missing one.
### Maximum score
The highest membership risk score that is approved by rule. A grant at exactly this score is approved; one point higher goes to a reviewer, and the block says so. The field accepts 0 up to the ceiling described above, 49 with the shipped policy, and shows that ceiling beside the input. A stored value above the ceiling is pulled back down when the screen loads, and again on every save.
With the shipped bands, a maximum of **20** approves the quiet end of Low: birthright grants that were recently certified, dated, and hold a Low entitlement. Raising it to 40 approves most of Low. Setting it at the ceiling approves everything below High, which is a large share of most populations, and the block warns you at that point. Start at 20, look at what was approved, and raise it in steps.
If the membership filter above is set at or above this number the rule can never fire, because every grant that survives the filter already scores too high to approve. The two settings are meant for different campaign shapes, not for use together.
### Reviewer visibility
Whether reviewers see the grants the rule approved. In this release the only option offered is **Shown as pre-approved**: the item appears in the reviewer's list, marked as decided by the system with its decision pre-set to certify, and the reviewer can confirm or overturn it. A hidden mode exists in older configurations but is not offered, and it does not in fact remove items from reviewer lists.
## Auto-certified items
This is the section reviewers should read.
**What it means.** An auto-certified item was approved by the rule above, at launch, before any reviewer opened the campaign. Nobody looked at it. The justification is that its membership risk score was low: the entitlement is not sensitive, the grant was made through a governed path, it is dated, it has been certified before, and nothing about it has changed.
**What was recorded.** The item carries a Certified outcome with the moment of launch as its decision date, marked as an automatic decision by the system rather than by a named reviewer. Its note reads, for example, *Auto-certified: membership risk 12.0 (LOW) is within the auto-certify threshold 20.0*. The score and band at launch are kept with the item, so the number the rule judged is preserved even if the score moves later.
**How you see it.** On the reviewer screen the row carries a blue **Auto** pill with a small robot, and its decision is already set to certify. A user or entitlement row that groups several grants shows the robot with a count of how many of them were pre-approved. Hover either for the reason.
**What you should do with them.**
* Do not re-review them one by one. They are decided, and the decision is defensible: the rule and the score are on record.
* Spot-check a sample. Open five or ten and confirm they look the way a low-risk grant should.
* Look for anything auto-certified that surprises you. A surprising auto-certified item is a signal that the policy or the maximum score is wrong, not that this one item is wrong. Note it and raise it with whoever owns the risk configuration.
* Know that you can still overturn one. Flip its decision to revoke and submit it like any other row. The record then shows both the system's approval and your revocation. Once you submit, the decision is locked.
* Re-tune before the next campaign rather than fighting this one.
{% hint style="warning" %}
**The campaign's CSV report does not flag auto-certified items.** The on-screen rule text promises a "System Approved" flag in final reports; that column does not exist. If you need to show an auditor which items were approved by rule, use the item-level record, where the decision note begins with *Auto-certified*.
{% endhint %}
**When not to use it.** Under a regulatory regime that requires an explicit human attestation on every item, do not enable auto-certification. Use the threshold to shrink the population instead, and leave every surviving item to a reviewer. A campaign in which every item was auto-certified goes straight to sign-off by the campaign manager, with no reviewer step.
## What the preview shows
The **Preview** tab applies the membership filter exactly as a launch would, and shows what it removed in the **Review exclusions** panel. Risk appears there in two places:
* An access tile, **Access — Membership risk below threshold**, counting the individual grants dropped. Each carries the explanation *Access risk score is below the configured membership risk threshold of N.*
* The **User — all access filtered** tile, which absorbs anyone left with nothing to review. Their explanation reads *All of this user's access scored below the membership risk threshold of N, so there is nothing to review.*
Use the preview to size the campaign before launch: read the in-scope count and lower the threshold until the volume matches the review capacity you have. The preview does not simulate the automation rule, so it shows what will reach the campaign, not how much of it will be approved on arrival.
## A worked campaign
A quarterly campaign over the 12,000 employees and contractors in scope from the other tabs. The owner wants reviewers to spend their time on risky access and to stop confirming birthright grants by hand.
**Risk tab.** Membership risk score on, at 50, which is High and up under the shipped policy. Enable Beta Features on. Automation on, Maximum score 20, Shown as pre-approved. A campaign manager is set.
**What the preview showed.** The 12,000 people hold 96,000 grants. 88,300 scored below 50 and were dropped, listed under **Access — Membership risk below threshold**. 4,900 people were left with nothing to review and moved into **User — all access filtered**. 7,700 grants across 7,100 people remained.
**What launched.** The rule approved nothing, because every surviving grant scores at least 50 and the maximum is 20. All 7,700 grants went to 140 reviewers, about 55 each.
**What the owner changed next cycle.** With the filter doing the narrowing and the rule idle, they turned the filter off and kept the rule: all 96,000 grants entered, 61,000 scoring 20 or below were approved automatically, and 35,000 went to reviewers with the riskiest at the top of each queue. Same reviewers, more coverage, and every approval on record with its score.
## The identity risk threshold has been retired
Earlier releases also offered an **Identity risk score** filter that kept a person out of the campaign entirely when their aggregate score was too low, and a truth table describing how the two filters combined. Both are gone.
The reason is that a certification reviews grants, and a person's aggregate score is the wrong tool for choosing which grants to review: it could keep a Critical grant out of the campaign because its holder looked unremarkable overall. Existing certifications lose the setting on upgrade and scope on membership risk alone. A person's identity risk is still computed, and administrators can still read it in the Webconsole; it just no longer decides scope.
### How the two thresholds used to combine
While both filters existed, they were a hierarchical AND: the identity filter chose the people, then the membership filter chose which of their grants were reviewed. A person below the identity threshold was left out entirely, even when they held a Critical grant.
Nothing combines any more. There is one threshold, it applies to grants, and the banner on the tab states in one sentence what it is doing.
## Related
* [Risk policies](/administration-guide/risk/policies.md) — where the bands and the ceiling this tab reads are set
* [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md) — the badges, the Auto pill and the explanation
* [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md) — scope, preview and launch
* [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md) — reviewer steps, campaign manager and sign-off
* [Work an SoD violation to closure](/administration-guide/governance/sod/sod-triage-remediation-and-evidence.md) — why a violating item is never auto-certified
*Applies to OpenIAM 2026.9.1. Last reviewed 4 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/risk/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.