They should stop when manual work becomes the default mechanism for validating entitlements, reconciling records, or approving access. At that point, the programme is compensating for broken data and weak ownership rather than operating controls. Persistent manual effort is a sign that automation will keep failing until the identity model is cleaned up.
Why This Matters for Security Teams
Manual IAM work becomes a control smell when it is used to compensate for broken entitlement data, unclear ownership, or missing lifecycle automation. At that point, access reviews, approvals, and reconciliations are no longer safeguards so much as evidence that the identity model is not trustworthy. NIST’s NIST Cybersecurity Framework 2.0 frames governance and continuous improvement as core security outcomes, not admin chores, which is exactly why persistent manual effort should be treated as a governance failure.
The risk is sharper for secrets and non-human access because long-lived credentials, stale entitlements, and inconsistent offboarding create hidden privilege that automation can keep inheriting. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which makes human-led cleanup feel productive while leaving the underlying exposure intact. In practice, many security teams encounter the real scale of manual IAM debt only after a secrets leak or access review backlog has already turned into an incident.
How It Works in Practice
The practical question is not whether any manual work is acceptable, but whether it is still the primary mechanism for keeping identity state accurate. Some manual control will always remain for exception handling, investigations, and approved escalations. Current guidance suggests that routine entitlement validation, credential rotation, and access reconciliation should be automated wherever the same pattern repeats across users, workloads, or environments.
For non-human identities, that usually means moving from ticket-driven approvals to policy-driven workflows. A mature programme ties access to workload identity, short-lived credentials, and event-based revocation so that the identity layer can react faster than a person can process a queue. The NIST Cybersecurity Framework 2.0 supports this shift by emphasizing continuous monitoring, resilience, and measurable governance outcomes rather than periodic manual checks.
Operationally, teams should ask four questions:
- Is a person approving something that a policy engine could evaluate at request time?
- Is manual reconciliation being used because source-of-truth ownership is unclear?
- Are secrets, API keys, or service accounts being rotated only when someone remembers?
- Does the process fail if the one analyst who knows the exception leaves?
When the answer is yes, manual work is no longer a safeguard. It is a signal that the control plane is missing automation, lifecycle state, or authoritative data. NHIMG’s Azure Key Vault privilege escalation exposure research is a useful reminder that over-permissive identity paths often hide behind apparently routine administration. These controls tend to break down when entitlement data is fragmented across cloud platforms and spreadsheets because no single owner can validate changes fast enough.
Common Variations and Edge Cases
Tighter automation often increases governance overhead at first, so organisations have to balance speed of remediation against the cost of cleaning up identity data and approval paths. That tradeoff is real, especially in regulated environments where exceptions must be documented and change control cannot be removed entirely.
Best practice is evolving, but one clear dividing line is this: manual work is still defensible for rare exceptions, break-glass access, and one-off investigations, while repeated approval of the same pattern is a sign that the process should be redesigned. The same applies when legacy applications cannot support modern federation or short-lived secrets. In those cases, manual handling may be unavoidable temporarily, but it should have an end date and a migration plan.
Teams also need to distinguish between human review and human execution. A reviewer can approve a high-risk request, but the actual provisioning, revocation, and evidence collection should be system-driven where possible. That is especially important when access spans many accounts, clouds, or service identities, because manual operations scale poorly and often miss drift. NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is exactly the kind of pattern that should trigger automation rather than more spreadsheet tracking. Where service ownership is unclear or environments are highly fragmented, manual IAM work stops being acceptable because it cannot keep pace with identity drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Manual IAM debt is a governance and ownership problem. |
| NIST CSF 2.0 | PR.AC-1 | Access should be based on managed, reviewed entitlements not ad hoc admin work. |
| NIST AI RMF | Manual control is a risk management signal when identity state is not trustworthy. |
Use AI RMF governance to assign accountability for identity accuracy, exception handling, and automation goals.
Related resources from NHI Mgmt Group
- How should organisations reduce manual compliance work without losing audit defensibility?
- How should organisations stop auto-sync from turning desktops into repositories of credentials?
- Should organisations treat agent discovery as part of IAM or platform operations?
- How can organisations use standards work to improve identity security?
