They should measure whether the requested change was completed in the application, not whether a ticket was closed. Useful signals include verified deprovisioning, reduced orphaned account counts, and fewer exceptions that rely on email or spreadsheets. If evidence lives outside the system of record, the process is not yet controlled.
Why This Matters for Security Teams
Manual identity work often looks successful because the workflow endpoint is visible: a ticket closes, an approver signs off, and an analyst marks the request complete. That does not prove the identity changed in the application. Security teams need evidence in the system of record because identity controls are only real when access is actually removed, rotated, or scoped. NIST Cybersecurity Framework 2.0 frames this as measurable control execution, not administrative completion, and NHIMG research shows why the gap is material: only 20% of organisations have formal offboarding and revocation processes, while 91.6% of secrets remain valid five days after notification in incident response contexts.
That is why teams should measure verified outcomes, not process motion. If the request was to remove an account, did the account disappear or lose the target entitlement? If the request was to revoke a secret, did the token stop authenticating? The most useful evidence is directly tied to application state, not email approvals or spreadsheet tracking. The Ultimate Guide to NHIs explains why lifecycle verification matters, and the Top 10 NHI Issues shows how often gaps persist when processes are not anchored to actual control points. In practice, many security teams encounter the failure only after an audit, incident, or orphaned account review reveals that closed tickets did not equal completed identity changes.
How It Works in Practice
Teams know manual identity processes are working when they can reconcile a request to a verifiable change in the target system, then retain evidence that the change persisted. The control should be checked at the point where access exists: the application, directory, vault, cloud console, or API gateway. A closed ticket is an administrative artifact; it is not proof of enforcement.
A practical verification model usually includes three layers:
Requested action defines what should change, such as deprovisioning, privilege reduction, or secret revocation.
System evidence confirms the change occurred, such as account deletion, disabled login, removed group membership, or an invalidated token.
Post-change validation checks that the old path no longer works, including failed authentication, absence of orphaned access, and no reappearance after sync jobs.
This is especially important for NHIs because service accounts, API keys, and certificates can remain active long after the human request is considered complete. NHIMG’s Lifecycle Processes for Managing NHIs stresses lifecycle visibility, while the NIST Cybersecurity Framework 2.0 supports outcome-based control checking across identify, protect, detect, respond, and recover activities. The right KPI is therefore not “tickets closed,” but “confirmed state changed and remained changed.”
Security operations can strengthen the signal by sampling completed requests and re-running validation from the authoritative source of truth, then comparing results against access logs and inventory records. This makes it possible to spot manual workarounds such as email approvals, spreadsheet exceptions, or delayed admin actions that never reached the application layer. These controls tend to break down when the organisation lacks a reliable inventory of identities and target systems because verification cannot be automated against assets that are not consistently known.
Common Variations and Edge Cases
Tighter verification often increases operational overhead, requiring organisations to balance assurance against analyst time and application constraints. That tradeoff is real, especially where older systems lack APIs, where business owners still approve changes by email, or where different teams own the identity store and the application separately. Current guidance suggests accepting some manual steps only when they still end in system-backed validation.
There is no universal standard for this yet, but best practice is evolving toward evidence-based completion checks. For high-risk actions, teams should require stronger proof, such as a screen capture alone is not enough, while log evidence, API confirmation, or a post-change query is better. For low-risk changes, sampling may be acceptable if the process is stable and errors are rare. However, when orphaned accounts, stale secrets, or exception-heavy workflows are common, manual completion metrics can become misleading very quickly.
NHIMG’s research on the 52 NHI Breaches Analysis shows how weak lifecycle control often hides behind apparently successful administrative handling. The practical question is simple: can the team prove that the old access path stopped working and the new state is the one now enforced? If not, the manual process is not yet under control, even if the queue looks clean.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Manual completion fails when NHI credentials are not rotated or revoked. |
| NIST CSF 2.0 | PR.AC-4 | Access changes must be validated in the target system, not just approved. |
| NIST AI RMF | Outcome-based verification supports accountable control monitoring and governance. |
Define measurable identity outcomes and check that manual workflows produce them consistently.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
