> 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/factors.md).
# Risk factor reference
What each built-in risk factor measures, why it is a warning sign, what its settings do, and which level of risk it feeds.
This page is for the administrator or compliance owner who tunes risk scoring. It explains the three things a score can be attached to, then every built-in factor: what it measures, why it matters, what it looks like on a real person, and what each setting does. Read the [overview](/administration-guide/risk/overview.md) first if the idea of a risk score is new to you. The weights, toggles and strategies that combine factors into one number are on [Risk policies](/administration-guide/risk/policies.md).
**On this page**
* [Part A. Risk subject levels](#levels)
* [Entitlement level](#level-entitlement)
* [Membership level](#level-membership)
* [Identity level](#level-identity)
* [How a factor is bound to a level](#levels-binding)
* [Part B. The factors](#factors)
* [Time windows and decay](#factor-decay)
* Entitlement level: [Entitlement Sensitivity](#factor-entitlement-sensitivity)
* Membership level: [Certification Age](#factor-membership-certification-age) · [Expired Membership](#factor-membership-expired) · [Membership Duration](#factor-membership-duration) · [Membership Origin](#factor-membership-origin) · [Reinstated Access](#factor-membership-reinstated) · [Stale Membership](#factor-membership-age)
* Identity level: [Dormant Identity](#factor-identity-dormant)
* [Factors at a glance](#factors-at-a-glance)
## Part A. Risk subject levels
A risk score is always attached to something. OpenIAM scores three kinds of thing, called **subject levels**. Every factor belongs to exactly one level, and one policy governs all three. Keep the three apart and most of the configuration explains itself.
| Level | Attached to | The question it answers | Who acts on a high score |
| ----------- | --------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Entitlement | A role or a group, regardless of who holds it | How dangerous is this access in anyone's hands? | The application or role owner |
| Membership | One person's grant of one entitlement | Given how this person got and uses this access, how much attention does this one row deserve? | The reviewer of that row |
| Identity | A person | Taking all of their access together, how much attention does this person deserve? | The person's manager, or the campaign owner deciding scope |
Resources are not scored. Only roles, groups and the memberships of roles and groups carry a score.
### Entitlement level
The entitlement score describes the access itself. It is the same number for every holder, because it depends only on the role or group. In this release one factor feeds it: [Entitlement Sensitivity](#factor-entitlement-sensitivity), which reads the risk level you set on the role or group.
`Payments-Admin` can move money, so it carries the **Critical** risk level and scores **90** with the shipped settings. `Finance-Reports-Read` can only open a dashboard, carries the **Low** level and scores **25**. Those two numbers do not change whether Maria Rossi, Tom Becker or nobody at all holds the access.
The entitlement score matters beyond its own level. It is the **floor** of every membership score for that entitlement: context can raise a membership above it, never below it.
### Membership level
The membership score describes one grant: this person, this entitlement. It starts from the entitlement's score and adds context about the grant. How was it given? How old is it? Does it have an end date, and has that date passed? When was it last certified? Was it revoked in a review and then granted again?
Maria has held `Finance-Reports-Read` for three years. It came from a birthright rule when she joined, has no end date, and was certified seven months ago. With the shipped settings her membership scores **37**, a little above the entitlement's own 25, because a long-standing open-ended grant that is due for its next review adds some context.
Tom holds `Payments-Admin`. An administrator assigned it to him directly three weeks ago, for the length of his 60-day contract, and nobody has ever certified it. His membership scores **98**. The entitlement's 90 is the floor; the direct assignment and the missing certification lift it further.
Same entitlement, two people, two different membership scores. That is what the membership level is for. It is the number a reviewer sees on each row of a certification and the number a campaign's membership threshold filters on.
### Identity level
The identity score describes a person. It is **not** an average of their memberships. It starts from their single riskiest membership, adds a little for every further membership that is high risk, and brings in identity-only signals such as whether the person still logs in.
Maria's riskiest membership is 37, none of her access is high risk, and she logs in every day. Her identity score is **37**. Tom's riskiest membership is 98 and it is his only high-risk grant. His identity score is **99**.
This is the number a campaign's identity threshold filters on, and the number shown next to the user's name on the reviewer screen. A high identity score says "look at this person's whole set of access", not "one row is wrong".
### How a factor is bound to a level
Every factor declares the level it scores, and the level cannot be changed. The factor catalogue shows it by grouping the factors under their level. A membership-level factor can only ever contribute to a membership score; it cannot contribute to an identity score or an entitlement score.
The policy does not change that. One policy holds the factors of all three levels, and the engine only ever puts a factor into the score of its own level, so attaching a factor is not a choice about which score it feeds.
The restriction exists because each level answers a different question about a different thing. If a person's login habits could change the score of a role that a thousand people hold, no score would mean anything. The levels stay separate so that each number is about exactly one thing, and so that a breakdown can always say which thing.
The three levels still connect, in one direction. The entitlement score is the floor of each membership score, and the riskiest membership score is the starting point of the identity score. Details of that arithmetic are on [Risk policies](/administration-guide/risk/policies.md#user-policy-aggregation).
## Part B. The factors
Eight factors ship with the product. Each produces a **factor score from 0 to 100** for one subject. Zero means "this signal sees nothing worth flagging", or "this signal has no data for this subject". The policy then combines the factor scores of a level into the subject's score, using each factor's weight. How the combination works, and what a weight means, is on [Risk policies](/administration-guide/risk/policies.md#user-policy-factor-weight).
Every factor row on a policy shows the same things: the name, the decay chip, an enable toggle, a weight, and an expander with the factor's own settings. The level is the heading the row sits under, not a mark on the row itself. The settings are what this page documents. Each factor's section closes with the case, if any, where switching it off is the right call.
{% hint style="info" %}
**Factor names are fixed.** The names below are the names on screen. They are not translated, and a reviewer may see a slightly different wording for the same factor in the score breakdown. The factor **key** in the code span under each heading is the stable identifier.
{% endhint %}
### Time windows and decay
Each factor row carries a small chip that reads **No decay** or **Decay · 90d**. It shows two settings on the factor's catalogue entry: whether a contribution fades over time, and over how many days.
Every built-in factor ships with **No decay**, and that is what to leave it on. The factors that depend on the calendar, such as Stale Membership or Dormant Identity, already change on their own as days pass: a membership that was fresh in March is aging by June without any decay setting. The nightly recompute picks that up.
{% hint style="warning" %}
**Do not rely on the Decay setting in this release.** The chip can be switched to Decay with a window, but the fade is not applied to stored scores yet. A factor set to Decay · 90d scores exactly as it would on No decay. Leave it alone until a release note says otherwise.
{% endhint %}
### Entitlement Sensitivity
`builtin.entitlement.sensitivity` · Entitlement level
**What it measures.** The risk level you have set on the role or group. OpenIAM lets you classify each role and group with a risk level such as Low, Medium, High or Critical. This factor turns that label into a number using a small table of scores, one per level.
**Why it is a risk signal.** It is the only signal that knows what the access can *do*. Every other factor describes how a grant was made or how it is used; this one says whether the thing granted can move money, delete data, or only read a report.
**Real-life example.** `Payments-Admin` can move money. `Finance-Reports-Read` can only open a dashboard. In a certification both are one row, with one checkbox each, and without this factor they look equally urgent. With it, `Payments-Admin` scores 90 and `Finance-Reports-Read` scores 25 before any holder is considered. Every membership of `Payments-Admin` therefore starts from 90, and a reviewer sorting by risk sees them first.
**What happens when it goes wrong.** A role with no risk level at all scores **0**, and every membership of that role starts from a floor of 0. If you see a money-moving role with a low score, the first thing to check is whether anyone classified it.
#### Settings
The expander shows one row per risk level under **Risk level scores**.
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ------------------------- | --------------------------------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Score for each risk level | The factor score given to every entitlement carrying that level | Critical 90 · High 75 · Medium 50 · Low 25 | Keep the order Critical > High > Medium > Low, and keep the gaps roughly even | Raising a level pushes every entitlement at that level, and every membership of it, up together. Lowering Low toward 10 makes genuinely harmless access read as Low rather than Medium (see the note below) |
A risk level you create after installation appears in this list with no score. Until you give it one, entitlements at that level score 0. Nothing warns you; the level simply contributes nothing.
{% hint style="info" %}
**Low sits exactly on the Medium line.** With the shipped scores, a Low entitlement scores 25, and with the shipped band thresholds 25 is the first Medium score. If you want Low-level access to show as Low, lower the Low score to about 10. Raising [Medium at](/administration-guide/risk/policies.md#user-policy-medium-threshold) would work too, but one threshold set now bands every score, so it would move memberships and identities as well.
{% endhint %}
**When to turn it off.** Never, in practice. It is the only entitlement-level factor, so disabling it gives every entitlement a score of 0 and removes the floor from every membership score.
### Certification Age
`builtin.membership.certificationAge` · Membership level
**What it measures.** How many days have passed since a reviewer last certified this person's access to this entitlement, in any campaign. Access that has never been certified is treated as its own case.
**Why it is a risk signal.** A grant nobody has confirmed recently is a grant nobody has taken responsibility for. The longer since the last confirmation, the more likely the need has changed.
**Real-life example.** Maria's `Finance-Reports-Read` was certified in a campaign seven months ago. It falls in the **Due for review** band and adds 25. Tom's `Payments-Admin` has never been certified at all, so it adds the **Never certified** score of 50. Two grants, and the one that has never had a human look at it scores higher, which is the point.
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ----------------------- | -------------------------------------------------------------------------------------------------- | --------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Due for review at | Days since the last certification after which the grant leaves the Recently certified band | 90 days | Somewhere near your review cycle | Raise it and grants stay "recent" longer; lower it and they become due sooner |
| Overdue at | Days after which the grant is Overdue | 365 days | About one cycle past the point where you would expect a review | Raise it if annual reviews are your norm and you do not want a 13-month gap to read as overdue |
| Axis maximum | The right-hand end of the timeline drawn in the expander. Display only; it does not affect scoring | 1095 days | Leave it | No effect on scores |
| Recently certified adds | Score while in the first band | 0 | 0 | Raising it makes recently confirmed access carry risk anyway; there is rarely a reason |
| Due for review adds | Score while in the middle band | 25 | 15 to 40 | Raise it to make an overdue review weigh more than the grant's origin; lower it to let other signals lead |
| Overdue adds | Score once Overdue | 50 | 40 to 75 | Raise it to force long-uncertified access toward the top of the queue |
| Never certified adds | Score for a grant with no certification on record | 50 | 25 to 75 | See the misconfiguration note |
The bands are read with the first cutoff excluded from the first band: 89 days is Recently certified, 90 days is Due for review. Band scores must not decrease from left to right.
{% hint style="warning" %}
**Before your first campaign, everything is "never certified".** Every membership then adds 50 from this factor alone, which lifts every membership score by the same amount and tells you nothing. Either lower **Never certified adds** to about 25 until the first cycle has run, or accept the uniform lift and read scores relative to each other.
{% endhint %}
If the certification service cannot be reached and the grant carries no certification record of its own, the factor scores 0 with the explanation that certification history is unknown. That is a data gap, not a clean bill of health.
**When to turn it off.** Only while you have no certification history at all and do not want the uniform "never certified" lift. Turn it back on after the first campaign.
### Expired Membership
`builtin.membership.expired` · Membership level
**What it measures.** For a grant whose end date has already passed but which is still present, how many days ago it expired. A grant with no end date, or whose end date is in the future, scores 0 here.
**Why it is a risk signal.** An expired grant that is still in place means the process that should have removed it did not run. The longer it lingers, the more likely it has been forgotten.
**Real-life example.** Tom's contract ends in six weeks. If his `Payments-Admin` is still in place 100 days after that, this factor puts it in the **Lingering** band and adds 25. A year later, if it is still there, it is **Orphaned** and adds 50. Today, with the end date still in the future, it adds 0.
An expired membership is scored only by this factor. The age, duration and origin factors treat it as having no data, because a grant that is no longer in force has no meaningful age or grant path.
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| --------------------- | ----------------------------------------------------------------------------- | --------- | -------------- | ----------------------------------------------------------------------------------------------------- |
| Lingering at | Days past the end date after which the grant leaves the Recently expired band | 90 days | 30 to 90 | Lower it if your clean-up process is supposed to run weekly; raise it if a quarter of slack is normal |
| Orphaned at | Days past the end date after which the grant is Orphaned | 365 days | 180 to 365 | Lower it to escalate forgotten grants sooner |
| Axis maximum | Timeline display only | 1095 days | Leave it | No effect on scores |
| Recently expired adds | Score in the first band | 0 | 0 to 10 | Raising it flags every expired grant immediately, even if clean-up is one day late |
| Lingering adds | Score in the middle band | 25 | 25 to 50 | Raise it if an expired-but-present grant should always reach a reviewer |
| Orphaned adds | Score once Orphaned | 50 | 50 to 100 | Raise it toward 100 if an orphaned grant should be the first thing every reviewer sees |
**When to turn it off.** There is no good reason. It scores 0 for every grant that is not expired, so it costs nothing when clean-up works and it is the only factor that notices when clean-up does not.
### Membership Duration
`builtin.membership.duration` · Membership level
**What it measures.** The span the grant was made for: from its start date to its end date. A grant with no end date is **indefinite** and is treated as its own case, separate from the bands.
**Why it is a risk signal.** Access granted for a long or unlimited time is access nobody has to justify again. A short, dated grant carries its own expiry; an indefinite one relies entirely on a review to end it.
**Real-life example.** Tom's `Payments-Admin` was granted for the 60 days of his contract. That is a **Short** span and adds 0. Maria's `Finance-Reports-Read` has no end date, so it adds the **Indefinite grant** score of 100, the maximum a factor can give. Her grant is stable and appropriate, but it will never end on its own, and that is what this factor points at.
{% hint style="warning" %}
**If nearly all of your grants are open-ended, this factor stops telling you anything.** Every indefinite grant adds the same 100, so the lift is uniform and the factor no longer separates one membership from another. Lower **Indefinite grant adds** to somewhere between 25 and 50, or turn the factor off, until end dates are part of how you grant access.
{% endhint %}
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| --------------------- | ------------------------------------------------------ | --------- | -------------- | ------------------------------------------------------------------------------------------- |
| Medium at | Span in days after which a grant leaves the Short band | 90 days | 30 to 180 | Lower it if a quarter already counts as a long grant in your organization |
| Long at | Span after which a grant is Long | 365 days | 180 to 730 | Raise it if multi-year grants are normal and you only want to flag the extreme ones |
| Axis maximum | Timeline display only | 1095 days | Leave it | No effect on scores |
| Short adds | Score for a Short span | 0 | 0 | Leave it |
| Medium adds | Score for a Medium span | 25 | 10 to 30 | Raise it to make span matter more than origin |
| Long adds | Score for a Long span | 50 | 25 to 60 | Lower it if long dated grants are your normal practice |
| Indefinite grant adds | Score for a grant with no end date | 100 | 25 to 100 | See the note above. 100 makes every open-ended grant the maximum; 25 to 50 makes it a nudge |
A grant with an end date but no start date has no measurable span and scores 0.
**When to turn it off.** When you do not use end dates at all. Then every grant is indefinite, every grant adds the same score, and the factor only inflates numbers.
### Membership Origin
`builtin.membership.origin` · Membership level
**What it measures.** How the access was granted, read from the membership tag stamped when the grant was made: an administrator assigned it directly, the system assigned it as part of an ownership relationship, an approved access request granted it, a business rule granted it as birthright, or a custom tag of yours. See [Membership tags](/administration-guide/governance/certification/membership-tags.md) for how tags are stamped.
**Why it is a risk signal.** The grant path tells you how much control was applied when the access was given. A birthright rule was designed, reviewed and applies to everyone in the same situation. A direct administrator assignment bypassed the request and approval process entirely.
**Real-life example.** Maria's `Finance-Reports-Read` came from the Finance birthright rule, the most governed path, and adds 10. Tom's `Payments-Admin` was assigned directly by an administrator, the least governed path, and adds 75. That single difference in how the two grants were made is worth 65 points of context before anything else about the two people is considered.
#### Settings
The expander shows **Unknown origin adds** first, then one row per membership tag under **Grant path scores**.
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ------------------------- | -------------------------------------------------------------- | ------- | ------------------------------------------- | ------------------------------------------------------------------------- |
| Unknown origin adds | Score for a grant carrying no origin tag at all | 50 | 0 until tagging is in place, then 50 to 75 | See the note below |
| Admin assignment | Direct grant by an administrator, outside request and approval | 75 | 60 to 90 | Raise it if direct assignment is supposed to be rare in your organization |
| System assignment | Grant created by an ownership or administrative relationship | 60 | 40 to 75 | Lower it if system relationships are routine and well controlled |
| Access request assignment | Grant through an approved access request | 25 | 10 to 40 | Lower it if your approval flow has strong controls |
| Birthright assignment | Grant by a business rule | 10 | 0 to 25 | Leave it low; the rule itself is the control |
| Any custom tag | Your own tags start here | 50 | Set it deliberately for each tag you create | A tag you never score contributes 0, not 50 |
When a grant carries several origin tags, the least governed one wins: admin assignment first, then system, then access request, then birthright, then custom tags. A grant with several origins is a data problem to fix rather than a scoring subtlety to rely on.
{% hint style="warning" %}
**This is the one factor that scores missing data.** Every other factor scores 0 when it has no information. Membership Origin scores **Unknown origin adds**, 50 by default, because not knowing how access arrived is itself a governance gap. If you have not started stamping origin tags, every membership in your system adds 50 here. Set **Unknown origin adds** to 0 until tagging is in place, then raise it.
{% endhint %}
**When to turn it off.** While no origin tags are being stamped yet, if you would rather remove the factor than zero its unknown score.
### Reinstated Access
`builtin.membership.reinstated` · Membership level
**What it measures.** Whether a reviewer revoked this person's access to this entitlement in a past certification, and the access is in force again with no later certification. It also knows how long ago the revocation was.
**Why it is a risk signal.** A human looked at exactly this grant and decided it should go. Its return without a new confirmation is one of the strongest signals a review can produce, and one that is invisible on a normal access list.
**Real-life example.** In the spring campaign Tom's manager revoked his `Finance-Reports-Read`. In June an administrator granted it to him again, directly, and it has not been certified since. This factor adds 75 to that membership. Without it, the grant looks like any other recent one.
Access that was never revoked in a review adds 0. Access revoked and then certified again adds 0, because a reviewer has confirmed the reinstatement.
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ----------------------------- | ---------------------------------------------------------- | -------- | -------------- | -------------------------------------------------------------------------------------------- |
| Reinstated access adds | Score for a grant that was revoked in a review and is back | 75 | 50 to 100 | Raise it to 100 if a reinstated grant should always be near the top of the queue |
| Ignore revocations older than | Revocations older than this many days no longer count | 730 days | 365 to 1095 | Lower it if roles change often enough that a two-year-old revocation is no longer meaningful |
A revocation exactly as old as the window still counts; one day older does not.
**When to turn it off.** Almost never. It scores 0 for anything that was never revoked, so it is silent until it has something to say. Consider a low score rather than off if revocations are routinely reversed for operational reasons in your organization.
### Stale Membership
`builtin.membership.age` · Membership level
**What it measures.** How many days ago the access was granted, for grants currently in force. It reads the start date of the membership.
**Why it is a risk signal.** Needs change. The longer since a grant was made, the more likely the reason for it has moved on, especially when the person has changed role or team.
**Real-life example.** Maria's `Finance-Reports-Read` was granted three years ago and is in the **Stale** band, adding 50. Tom's `Payments-Admin` was granted three weeks ago and is **Fresh**, adding 0. Notice that this is the one factor where Maria's stable access outscores Tom's new access. Age is a nudge toward re-examining old grants, not a verdict.
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ------------ | --------------------------------------------------------- | --------- | -------------- | ---------------------------------------------------------------------------------------- |
| Aging at | Days since the grant after which it leaves the Fresh band | 90 days | 60 to 180 | Raise it if a quarter is short in your organization |
| Stale at | Days after which the grant is Stale | 365 days | 365 to 730 | Raise it if you already review annually and do not want every one-year-old grant flagged |
| Axis maximum | Timeline display only | 1095 days | Leave it | No effect on scores |
| Fresh adds | Score while Fresh | 0 | 0 | Leave it |
| Aging adds | Score while Aging | 25 | 10 to 30 | Lower it to keep age a gentle signal |
| Stale adds | Score once Stale | 50 | 25 to 50 | Lower it if most of your access is long-standing and appropriate |
A grant with no recorded start date scores 0 with the explanation that its age is unknown.
**When to turn it off.** When start dates were not preserved for imported memberships, so that every grant reads as unknown. It would score 0 everywhere and only dilute the other factors.
### Dormant Identity
`builtin.identity.dormant` · Identity level · human users only
**What it measures.** How many days since the person last logged in to anything OpenIAM records a login for. A person who has never logged in is treated as dormant outright.
**Why it is a risk signal.** Access held by someone who no longer uses their account is access nobody is watching. Dormant accounts are a classic entry point, and they are the accounts most likely to belong to a leaver whose departure was not processed.
**Real-life example.** Maria logs in every working day, so this adds 0 to her identity score. If Tom's contract ends, his account stays, and 120 days later nobody has logged in as him, this factor adds 75 to his identity score. That lift is what gets a forgotten contractor account in front of someone.
#### Settings
| Setting | What it does | Default | Sensible range | If you raise it / lower it |
| ----------------------------------- | -------------------------------------------------------------------------------------- | ------- | -------------- | ------------------------------------------------------------------------------------------------------------------ |
| Days without a login before dormant | The person is dormant once more than this many days have passed since their last login | 90 days | 45 to 180 | Lower it to catch leavers sooner; raise it if long leave or seasonal work is common and you do not want it flagged |
| Dormant identity adds | Score added while dormant | 75 | 50 to 100 | Raise it to 100 if a dormant account should always be Critical |
Exactly 90 days is not yet dormant; 91 is. A person for whom no login information exists at all scores 0, with the explanation that account activity is unknown.
{% hint style="warning" %}
**If nobody's logins are recorded, everyone is dormant.** When people authenticate through systems that do not report logins to OpenIAM, every identity reads as never logged in and adds 75. Confirm that logins are being recorded before you trust this factor, and turn it off until they are.
{% endhint %}
**When to turn it off.** When OpenIAM does not see your users' logins. Otherwise leave it on.
### The factor catalogue screen
**Administration → Risk factor configuration** opens the page titled **Risk Factors**: every factor the product knows, whether or not a policy uses it. Each row shows the factor's name, description and key, its level, what it applies to, whether it is built-in, its default weight, whether it is active, and when it was last changed. Tabs filter by level and a search box matches name, key or description. Built-in factors cannot be edited or deleted here; their settings are tuned per policy on the [Factors tab](/administration-guide/risk/policies.md#factors-tab).
#### Applies to
Whether the factor scores **User** identities, **Non-human** identities, or **All**. Only Dormant Identity is limited to users, because a service account is not expected to log in. Non-human is reserved for a later release: a factor marked that way cannot be attached at membership or identity level, and no separate policy for non-human identities can be created yet.
#### Weight
The weight a policy receives when this factor is attached to it, from 0 to 1. Changing it affects future attachments only. The weight a score actually uses is the one on the policy's Factors tab, which is where you tune it; see [Weight](/administration-guide/risk/policies.md#user-policy-factor-weight). Every built-in factor ships at 1.0.
#### Active
The master switch for the factor. Switching it off retires the factor everywhere: it stops scoring on every policy it is attached to at the next recalculation, and it disappears from the **Add factor** dialog. Switch it back on and the attachments resume with the values they had. Retire a factor when nobody should use it; disable it on one policy when only that policy should ignore it.
### Factors at a glance
All eight factors ship enabled with a weight of 1.0 on their policy. What a weight means, and why 1.0 everywhere is simply an even average, is explained on [Risk policies](/administration-guide/risk/policies.md#user-policy-factor-weight).
| Factor | Key | Level | Default weight | What it favours |
| ----------------------- | ------------------------------------- | ----------- | -------------- | -------------------------------------------------- |
| Entitlement Sensitivity | `builtin.entitlement.sensitivity` | Entitlement | 1.0 | Access that can do damage |
| Certification Age | `builtin.membership.certificationAge` | Membership | 1.0 | Grants no reviewer has confirmed recently, or ever |
| Expired Membership | `builtin.membership.expired` | Membership | 1.0 | Grants past their end date that were never removed |
| Membership Duration | `builtin.membership.duration` | Membership | 1.0 | Long and open-ended grants |
| Membership Origin | `builtin.membership.origin` | Membership | 1.0 | Grants made outside request and approval |
| Reinstated Access | `builtin.membership.reinstated` | Membership | 1.0 | Grants a reviewer revoked that came back |
| Stale Membership | `builtin.membership.age` | Membership | 1.0 | Old grants |
| Dormant Identity | `builtin.identity.dormant` | Identity | 1.0 | People who no longer log in |
Custom factors, built from conditions in the factor catalogue, are not available in this release. The **New custom factor** button is present but disabled until a later release.
## Related
* [Risk management overview](/administration-guide/risk/overview.md) — what a score is and where it appears
* [Risk policies](/administration-guide/risk/policies.md) — weights, strategies, toxic factors and thresholds
* [Access certification and risk](/administration-guide/risk/certification.md) — how scores filter a campaign and drive auto-certification
* [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md) — what a reviewer sees and should do
* [Membership tags](/administration-guide/governance/certification/membership-tags.md) — the origin tags Membership Origin reads
*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/factors.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.