Identity teams are being told that continuous monitoring makes quarterly access certification obsolete, while their auditors still ask for signed review evidence, and both claims are only half right. A periodic access review asks a person whether an entitlement should exist; continuous access monitoring watches how access is used and how it changes, and reacts when something looks wrong. They catch different threats, produce different evidence and fail in different ways. This guide compares them on what each proves to an auditor, which threats each misses, the signals that feed monitoring, the typical failure modes, and a hybrid model where events trigger small, targeted certifications. It is for identity governance leads, IAM architects, control owners and internal auditors deciding how far to shift from campaigns towards real-time controls.
Key takeaways
- They answer different questions. A review asks "should this access exist?" and needs a business decision; monitoring asks "is this access being used safely right now?" and needs a baseline. Neither question substitutes for the other.
- Real-time cannot fully replace certification. Monitoring sees behaviour, not intent, so it misses dormant entitlements and toxic combinations that are never exercised until the day they are abused. A named human decision is still the only proof that someone accountable judged the access appropriate.
- Certification cannot catch fast changes. A privilege granted the day after a campaign closes stays unseen until the next one. Monitoring closes that window to minutes or hours.
- CAEP revokes sessions, it does not review entitlements. The OpenID Continuous Access Evaluation Profile shares events such as session-revoked and token-claims-change; it narrows the gap between a decision and its enforcement, but it does not make the decision.
- The hybrid model wins. Keep a slimmer periodic review for regulated and privileged scope, and let monitoring trigger micro-certifications when events occur: a role change, a new privileged grant, a dormant account waking up or a new toxic combination.
Definitions and scope
Access review (certification, recertification, user access review): a scheduled or triggered process in which an accountable person, usually a manager, application owner or entitlement owner, confirms or revokes each account and entitlement in scope, and the decision is recorded and the revocation carried out. NIST SP 800-53 Rev. 5 AC-2 requires accounts to be reviewed for compliance with account management requirements at an organisation-defined frequency, and AC-6(7) requires privileges assigned to defined roles or users to be reviewed to validate the need for them. The design of good campaigns is covered in the Access Reviews Guide, and the working procedure in the Access Review Checklist.
Continuous access monitoring: automated, ongoing evaluation of identity state and identity behaviour, with alerts or automated responses when something deviates from policy or baseline. It includes posture checks on entitlements (new privileged grants, separation-of-duties conflicts, unused access), behavioural detection (identity threat detection and response, or ITDR), and real-time enforcement signals between systems, such as Shared Signals Framework and CAEP events. AC-2(12) asks organisations to monitor system accounts for defined atypical usage and report it, and CA-7 asks for a continuous monitoring strategy with defined metrics, monitoring frequencies and response actions.
The question is not which to buy but which risks each covers, and how much of the periodic workload monitoring can safely absorb.
Side-by-side comparison
| Dimension | Periodic access review | Continuous access monitoring |
|---|---|---|
| Core question | Should this access exist for this person or identity? | Is this access changing or being used in a risky way? |
| Decision maker | Accountable human (manager, owner) | Rules, models and analysts; humans for escalations |
| Time to detect a bad grant | Up to the full review interval, often a quarter or a year | Minutes to hours, if a rule covers it |
| Coverage | Everything in scope, used or not | What generates signals: logins, grants, usage events |
| Sees dormant access | Yes, if usage context is shown to reviewers | Only if posture rules look for unused entitlements |
| Sees business context | Yes: the reviewer knows the job | Rarely: it infers from peers and history |
| Typical failure | Rubber-stamping under volume and deadlines | Alert fatigue and untuned baselines |
| Audit evidence | Population listing, reviewer, decision, timestamp, revocation proof | Rule definitions, alert records, response tickets, tuning history |
| Cost profile | Business time, concentrated in campaigns | Tooling and security operations time, continuous |
| Best at | Accumulated, unused and inappropriate entitlements; SoD sign-off | Sudden escalation, compromised identities, misuse of valid access |
What each proves to auditors
Auditors test a control by its design and by evidence that it operated over a period. PCAOB AS 2201, the US standard for audits of internal control over financial reporting, says evidence must show the control operated effectively for a sufficient period, that inquiry alone is not sufficient evidence, and that the risk of a control depends on factors including its frequency, the judgement involved and the competence of the person performing it. It also notes that automated controls carry lower risk when IT general controls over access, program changes and operations are effective. That shapes what each approach can prove.
- A review proves accountable judgement: a completeness-checked population, a reviewer who is independent of the access, a recorded decision and evidence that removals were made. That is a classic manual control with a clear owner, which is why auditors are comfortable with it.
- Monitoring proves detection and response: that defined conditions were watched, alerts were raised and someone acted. To rely on it, an auditor will want the rule logic, evidence the rules ran across the whole period, change control over the rules, and samples of alerts traced to closure. If the monitoring tool's own access and configuration are not controlled, the evidence is weak.
- Neither proves the other's point: a monitoring log showing no alerts does not show that anyone judged an entitlement appropriate; a signed review does not show that a privilege granted last week was noticed.
For ISO/IEC 27001:2022, Annex A 5.18 (access rights) expects access rights to be reviewed, and 8.16 (monitoring activities) expects networks, systems and applications to be monitored for anomalous behaviour. A certification auditor will look for both. See the ISO 27001 Certification Guide.
Threats each approach misses
| Threat | Periodic review | Continuous monitoring | Control that closes the gap |
|---|---|---|---|
| Dormant toxic combination (for example, create vendor and approve payment held by one person, never yet used together) | Catches it if SoD rules are applied to the review population and the reviewer understands the conflict | Misses it if detection is behavioural, because nothing happens until the abuse | SoD rule set evaluated on every grant, plus certification of standing exceptions |
| Sudden privilege escalation (attacker or insider adds themselves to an admin group) | Misses it until the next campaign | Catches it if grants to privileged groups are alerted (ATT&CK T1098 Account Manipulation) | Real-time alert plus event-triggered micro-certification |
| Valid account abuse (stolen credentials used normally) | Misses it: the access is legitimate | Catches it if behaviour deviates (ATT&CK T1078 Valid Accounts) | ITDR detections, session revocation through CAEP |
| Legitimate access used for illegitimate purposes | Misses it: the reviewer approves the job role | Catches it only with data-access baselines per identity | Usage monitoring on sensitive records, least privilege per case |
| Leaver whose credential or key survives offboarding | Catches the account if the population is complete; often misses keys and secrets | Catches it if use after termination is alerted | JML integration, credential inventory, post-termination use alert |
| Privilege creep from role changes | Catches it if mover events are reviewed | Partly: unused entitlements show as low usage | Mover-triggered certification of the old role's access |
| Unowned non-human identities | Misses them if not in scope; often no reviewer exists | Sees their activity, but cannot judge purpose | Ownership assignment, NHI-specific certification |
Two cases on the NHI Mgmt Group breach database show the split. In the Coupang Breach 2025, a former developer's token signing key was never revoked or rotated and remained usable for about a year after he left: an offboarding and credential review gap that a complete inventory and a post-termination use alert would each have narrowed. In the Coinbase Insider Breach 2025, outsourced support agents misused access they legitimately held for their jobs; no certification would have revoked it, and the lesson is to monitor what each identity reads relative to its open cases and its peers.
Signal sources for continuous monitoring
| Signal source | What it tells you | Limits |
|---|---|---|
| IGA or entitlement change feed | New grants, role changes, SoD conflicts at the moment they occur | Only covers connected applications; direct grants in unmanaged systems are invisible |
| Usage and last-used data | Which entitlements are exercised, by whom, how often | Coarse in many applications; last login is not last use of a specific permission |
| HR and JML events | Joiners, movers, leavers, contractor end dates, leave of absence | Only as timely as HR data; contractors and NHIs are often missing |
| ITDR and authentication logs | Anomalous sign-ins, token misuse, privilege escalation patterns | Behavioural, so blind to never-used entitlements |
| CAEP events over the Shared Signals Framework | session-revoked, token-claims-change, credential-change, assurance-level-change, device-compliance-change, session-established, session-presented, risk-level-change | Enforcement and session signals; no entitlement review semantics |
| Cloud and SaaS posture data | Over-privileged roles, unused permissions, external sharing | Platform-specific models; needs normalising |
| Data access logs | Volume and type of records an identity reads | Expensive to collect; needs per-role baselines |
CAEP 1.0 was published by the OpenID Foundation's Shared Signals working group on 29 August 2025. The specification lets receivers attenuate access to users, devices, sessions and applications; its closest event to an entitlement change is token-claims-change, whose example uses a role claim. Treat CAEP as the enforcement path that makes a revocation decision bite immediately, not as a review mechanism. See CAEP and Continuous Access Evaluation and the Shared Signals Framework Guide. For behavioural detection see the ITDR Guide.
Failure modes of each
Periodic reviews
- Rubber-stamping: reviewers approve hundreds of lines with no usage context. Approval rates near 100 per cent and decisions made seconds apart are the tell.
- Incomplete population: the listing comes from a report that misses local accounts, direct grants or service accounts, so the review certifies a subset.
- Self-review: a reviewer certifies their own access, or an administrator certifies the group that administers the system.
- Approved but not revoked: the decision is recorded but the change never reaches the target system.
Continuous monitoring
- Alert fatigue: every grant raises an alert, analysts stop reading them and real escalations are lost. Alert on privileged and SoD-relevant changes, not all changes.
- Untuned baselines: behavioural models flag the finance team every quarter end and miss slow, low-volume misuse.
- Coverage blindness: applications that emit no events are silently excluded, and a dashboard showing green is mistaken for full coverage.
- Detection with no decision: an alert that a dormant account has woken up is closed as "user confirmed", with no owner deciding whether the access should remain.
The hybrid model: event-triggered micro-certifications
A micro-certification is a review of a small number of items, sent to the right owner when a specific event occurs, with a short deadline and a default action if no one responds. It joins the two approaches: monitoring finds the moment, and a human makes the decision that monitoring cannot.
| Trigger event | What is certified | Reviewer | Suggested default if no response |
|---|---|---|---|
| Mover: department or manager change | Access from the previous role | New manager | Remove previous-role access after the transition window |
| New grant to a privileged group or role | The grant | Entitlement owner, independent of requester | Remove, or convert to time-bound access |
| New SoD conflict created | The conflicting pair, with a mitigating control | Control owner | Remove the most recently added entitlement |
| Entitlement unused beyond the threshold | That entitlement | Manager or owner | Remove |
| Dormant account used again | The account and its privileges | Manager or NHI owner | Disable pending confirmation |
| Identity risk raised (ITDR or CAEP risk-level-change) | Privileged entitlements of that identity | Security operations with owner | Revoke sessions, suspend privileged access |
| Owner of a non-human identity leaves | The NHI, its credentials and scopes | New owner | Rotate credentials, then disable if unclaimed |
The periodic campaign does not disappear. It shrinks to the scope where auditors and regulators expect periodic sign-off (financially significant applications, privileged access, standing SoD exceptions) and becomes a check that the event-driven process is complete, rather than the only control. NIST AC-2 already anticipates this: it asks for notification within defined times when accounts are no longer required, when users are terminated or transferred, and when system usage or need-to-know changes. See the Joiner-Mover-Leaver Guide and the Segregation of Duties Guide.
Decision guidance
- Keep periodic certification as primary: for applications in scope of SOX or similar financial controls, privileged and administrator access, and standing SoD exceptions, where an auditor expects an accountable sign-off for the period.
- Let monitoring lead: for high-volume, low-risk access (collaboration tools, read-only reporting), where removal of unused access can be automated and a periodic campaign adds little.
- Use micro-certifications: wherever a known event changes risk, especially movers, privileged grants and dormant accounts.
- Small organisations: start with a lean quarterly review of privileged and financial access plus three alerts: privileged group changes, use of accounts after termination and dormant account reactivation. That covers most of the gap at little cost.
- Large organisations: invest in a complete entitlement feed and usage data first; event triggers and auto-removal are only as good as the data behind them. Agree with external audit, before the period starts, which controls will be relied on and what evidence each produces.
Worked scenario: reducing a quarterly campaign
A listed retailer runs quarterly reviews of 40 applications with about 180,000 line items per campaign. Approval rates sit above 98 per cent and revocations are rarely verified.
- It splits scope: 11 financially significant applications and all privileged access stay in the quarterly campaign; the remaining 29 move to event-driven review with automated removal of entitlements unused for a defined period.
- It enables alerts on privileged group grants, new SoD conflicts, dormant account reactivation and post-termination sign-ins, and routes each to a micro-certification.
- It wires CAEP session-revoked events from its identity provider to the applications that support them, so a revocation decision ends sessions immediately.
- It runs both models in parallel for one quarter and compares what each removed and detected.
- It agrees the new design with its external auditor, documenting rule logic, change control over rules and alert-to-closure sampling.
The quarterly campaign shrinks to a fraction of its former size, each reviewer sees usage data, and privileged grants are reviewed within days rather than months. If the event pipeline fails, the rollback is simple: reinstate the full campaign for the affected applications.
Detection and measurement
- Revocation rate: percentage of certified items removed, per campaign and per micro-certification; a rate near zero suggests rubber-stamping.
- Time to review a privileged grant: median time from grant to accountable decision.
- Revocation verification: percentage of approved removals confirmed in the target system within the agreed time.
- Alert precision: percentage of access alerts that lead to a change or confirmed finding; track alongside volume per analyst.
- Coverage: percentage of applications and non-human identities feeding entitlement and usage data into monitoring.
- Dormant access: count of entitlements unused beyond the threshold that remain in place.
Framework mapping
| Framework | Reference | Supports |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2, AC-6(7) | Periodic account review and privilege review |
| NIST SP 800-53 Rev. 5 | AC-2(3), AC-2(12), CA-7 | Disabling inactive accounts, monitoring atypical usage, continuous monitoring strategy |
| NIST SP 800-53 Rev. 5 | AC-5 | Separation of duties, the basis of toxic combination rules |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, managed, enforced and reviewed with least privilege and separation of duties |
| NIST CSF 2.0 | DE.CM-03 | Personnel activity and technology usage monitored |
| NIST SP 800-137 | ISCM programme | Ongoing visibility into whether controls remain consistent with risk tolerance |
| ISO/IEC 27001:2022 | Annex A 5.18, 8.16 | Access rights review; monitoring activities |
| CIS Controls v8.1 | Control 5 Account Management | Processes and tools to assign and manage authorisation to credentials |
| PCAOB AS 2201 | Operating effectiveness over a period | Evidence expectations for both review and automated controls |
| MITRE ATT&CK v20 | T1078, T1098 | Valid account abuse and account manipulation that monitoring should detect |
Practitioner checklist
- Map every application and identity type to a model: periodic, event-driven, monitoring-led or a combination.
- Keep periodic certification for financially significant applications, privileged access and standing SoD exceptions.
- Define micro-certification triggers for movers, privileged grants, new SoD conflicts, unused entitlements and dormant account reactivation.
- Set a default action for every trigger so that silence leads to removal, not retention.
- Alert in real time on privileged group changes and on any sign-in after termination.
- Wire CAEP or equivalent session revocation so revocation decisions take effect immediately.
- Show usage data to every reviewer and track revocation rate per reviewer.
- Verify every approved removal in the target system.
- Include non-human identities with named owners, and certify them when the owner changes.
- Agree with auditors in advance which controls are relied on and the evidence each must produce.
Standards and references
- NIST: SP 800-53 Rev. 5
- NIST: SP 800-137 Information Security Continuous Monitoring
- NIST: Cybersecurity Framework 2.0
- OpenID Foundation: Continuous Access Evaluation Profile 1.0
- PCAOB: AS 2201 An Audit of Internal Control Over Financial Reporting
- CIS: Control 5 Account Management
- MITRE ATT&CK: Valid Accounts
Related NHI Mgmt Group resources: Access Reviews Guide · Access Review Checklist · Agent Identity Recertification · ISPM vs ITDR · JIT Access Guide