How should security teams run access certifications inside IT service management workflows without losing governance rigor?

Security teams should embed certification reviews where managers already work, but keep the approval model, evidence trail, and revocation logic aligned to identity governance policy. The goal is not convenience alone. It is faster action on access decisions, fewer workflow handoffs, and stronger adoption while preserving auditability, role ownership, and consistent review criteria.

Why This Matters for Security Teams

Access certifications fail when they become a box-checking exercise detached from the systems that actually grant or revoke privilege. In IT service management workflows, the risk is not the review itself, but the handoff gap between approval, evidence capture, and enforcement. That gap is where stale access persists, especially for NHIs, service accounts, and delegated admin paths. Current guidance in the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs both point to the same operational truth: lifecycle control matters more than periodic visibility alone.

The governance goal is not to move approvals into a ticketing tool and call it done. It is to preserve review criteria, approver accountability, and revocation traceability while meeting managers and system owners where they already work. That distinction matters because certifications only reduce risk when the outcome is actionable and enforced, not merely recorded. In practice, many security teams discover access drift only after audit sampling, incident response, or an over-privileged NHI has already been reused in ways the review never anticipated.

How It Works in Practice

A certification workflow inside ITSM should behave like a governed control, not a notification loop. The strongest pattern is to trigger review tasks from identity governance rules, route them through the service management system for operational follow-through, then push the decision back into the identity platform for enforcement. That preserves a clean audit trail while making the workflow familiar to managers, application owners, and service desk staff.

Practitioners usually get better results when the review task carries enough context to support a real decision. That includes the identity type, entitlement name, last-used date, source system, business owner, and a clear revoke or retain action. For NHIs, that context should also show whether the account has a bounded purpose, a documented secret rotation pattern, and any dependency that would break if access were removed. NHIMG’s NHI Lifecycle Management Guide and Regulatory and Audit Perspectives reinforce that lifecycle evidence and auditability must stay linked.

• Use ITSM to initiate and track the review, but keep identity governance as the system of record for entitlements and decision history.
• Pre-populate review tasks with usage data, ownership, risk rating, and the prior certification outcome.
• Require explicit revoke, retain, or exception decisions, with expiration dates for exceptions.
• Automate revocation where policy permits, then log the action back into the ticket for evidence.
• Escalate unresolved items before the certification window closes so silence does not equal approval.

For control design, align review evidence and revocation handling with the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev. 5 Security and Privacy Controls family, especially where access decisions must be provable after the fact. These controls tend to break down when the ITSM tool cannot enforce revocation back into the source system, because approvals then outpace actual privilege changes.

Common Variations and Edge Cases

Tighter certification control often increases workflow friction, requiring organisations to balance review rigor against manager burden and response time. That tradeoff is real, especially in high-volume environments where hundreds of entitlements or NHIs are reviewed in each cycle. Current guidance suggests focusing manual review effort on the highest-risk access, while using policy-based automation for low-risk, well-structured entitlements.

There is no universal standard for this yet, but the practical split is usually between human approval for exceptions and automated enforcement for routine renewals. For example, an ITSM workflow can auto-close dormant low-risk access, but it should route privileged access, production database roles, and cross-functional admin rights to named approvers with escalation rules. This is also where the risk of false confidence appears: a ticket can show “approved” even when a dependent secret was never rotated or an upstream group membership immediately reintroduced the same privilege. The Top 10 NHI Issues page is useful context for the recurring failure modes that surface in these workflows.

In practice, mature teams also define exception expiry, re-certification triggers after role change, and a separate path for emergency access that must be reviewed after the incident. That prevents the certification process from becoming a one-time paperwork event. The control breaks down most often in environments with fragmented identity sources, where the ITSM workflow has visibility into the request but not into the authoritative entitlement state.

Related resources from NHI Mgmt Group

• How should security teams run compliance workflows inside AI coding tools without losing governance control?
• How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
• How should security teams implement manager approval workflows for infrastructure access without creating bottlenecks?
• How should security teams run access reviews for non-human identities?