Notifications
Clear all
Topic starter
08/06/2026 5:04 pm
TL;DR: User access reviews are often run to satisfy SOX and PCI audit cycles, but ConductorOne argues they can also reduce standing privilege, surface unused access, and tighten controls around service accounts, contractors, and policy exceptions. That shift turns UARs from a box-ticking exercise into a practical identity security control.
NHIMG editorial — based on content published by ConductorOne: Beyond Checking the Box: How to Use UARs for Real Security
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
Questions worth separating out
Q: How should security teams use user access reviews to reduce risk, not just satisfy audits?
A: Security teams should scope user access reviews to likely risk, not only to fixed audit cycles.
Q: Why do user access reviews often miss the access that matters most?
A: They miss the access that matters most when the programme is built around calendar cadence instead of identity risk.
Q: What breaks when service accounts are left out of access review programmes?
A: When service accounts are left out, the programme loses visibility into some of the most persistent and over-permissioned identities in the environment.
Practitioner guidance
- Target reviews on unused access Run monthly UAR campaigns for accounts with no recent activity in high-risk systems such as AWS or production environments, then revoke access that reviewers cannot justify as necessary.
- Create a dedicated orphaned-account review path Separate accounts with no known owner from standard certification campaigns and require a named remediation owner before the review closes.
- Fold service accounts into recurring certification Assign explicit ownership for service accounts and review them on a frequent cadence, with special attention to accounts that are persistent and over-permissioned.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Campaign setup examples for unused access, orphaned accounts, and contractor production access
- Filter logic for direct versus inherited grants in access review campaigns
- CEL-based approval and revocation rules for policy-driven automation
- Practical workflow details for logging reviewer decisions into audit-ready reports
👉 Read ConductorOne's blog on using user access reviews for real security →
User access reviews beyond compliance: what should teams change?
Explore further
08/06/2026 7:03 pm
UARs become real security controls only when they are scoped to risk, not calendar cadence. Quarterly certification cycles satisfy compliance, but they do not tell a reviewer which entitlements are unused, inherited, or high blast radius. The control becomes materially stronger when it is aimed at the access most likely to be stale or excessive. That is the difference between proving review activity and actually reducing identity exposure.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Another finding from Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs shows that only 20% have formal processes for offboarding and revoking API keys.
A question worth separating out:
Q: Who should be accountable when a user access review finds unowned or excessive access?
A: Accountability should sit with the system or application owner first, then with the identity governance process that allowed the gap to persist. If the account is unowned, the organisation has an offboarding or provisioning problem as well as a review problem. The review should trigger remediation, not just a sign-off, because no one can responsibly certify unknown ownership.
👉 Read our full editorial: UARs as a security control: what identity teams should change
