Why do manual access requests create more risk in role changes and onboarding processes?

Why This Matters for Security Teams

Manual access requests create risk because role changes are not just a provisioning event, they are a control transition. When approvals move through email threads, chat messages, or ad hoc tickets, the organisation loses a reliable record of who approved what, under which policy, and when revocation should occur. That weakens least privilege, delays deprovisioning, and makes audit evidence harder to reconstruct.

For NHI governance, the same pattern shows up in service accounts, API keys, and automation credentials. NHIMG research notes that only 20% of organisations have formal offboarding and revocation processes for API keys, and 97% of NHIs carry excessive privileges in practice, which makes informal access handling especially dangerous. The lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it shows access should be governed as a state change, not a favour granted by inbox. In practice, many security teams discover the mismatch only after a role move has already left old access active.

Current guidance from OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward disciplined identity lifecycle control, but manual requests still bypass that discipline when the process is fragmented.

How It Works in Practice

The safer model is a governed workflow that ties every request to an identity event, a policy decision, and a revocation trigger. Onboarding should assign access based on role, department, location, system sensitivity, and existing entitlements, then issue only what is needed for the first task. Role changes should not preserve the old baseline by default. Instead, access should be re-evaluated, with prior permissions removed unless there is a documented reason to keep them.

For NHI-heavy environments, the pattern is similar but more operationally strict. A new service account, API key, or agent credential should be created with a defined owner, purpose, TTL, and revocation path. That aligns with the control intent described in Ultimate Guide to NHIs, where lifecycle discipline, visibility, and rotation are central, not optional. When paired with NIST SP 800-53 Rev. 5 Security and Privacy Controls, teams can map approvals to access enforcement, logging, and periodic review rather than relying on memory or inbox follow-up.

• Use one request path for all identities, with approval evidence captured in-system.
• Bind access to job role or workload purpose, then remove inherited rights during transition.
• Set revocation timing at approval time, not after the user leaves.
• Track temporary exceptions separately so they cannot become standing access.

These controls tend to break down when onboarding spans multiple systems with no single identity owner, because revocation responsibility gets split across teams and no one closes the loop.

Common Variations and Edge Cases

Tighter access control often increases onboarding friction, requiring organisations to balance speed against assurance. That tradeoff is real in acquisitions, emergency hires, contractor onboarding, and high-churn operational teams where waiting for full approvals can slow delivery. Current guidance suggests the answer is not to skip governance, but to predefine exception paths and use just-in-time access for short-lived needs.

There is no universal standard for every edge case yet, especially when a person changes roles while still supporting legacy systems or when an agentic workflow needs both human and machine approvals. In those situations, policy should distinguish between permanent entitlements and temporary task access, then require explicit expiry. For deeper context on why standing access becomes dangerous across identity lifecycles, the Top 10 NHI Issues page is a useful companion to the broader research. Teams should also treat manual approvals as a control exception, not the default operating model.

Where the process breaks most often is in decentralised organisations that let managers approve access without security or system ownership review, because the same mistake repeats at each transition and compounds into hidden privilege.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Why do temporary access and role changes create SoD risk?
• Why do onboarding processes often create access risk in the first week?
• Why do role changes create access risk in IAM programmes?