When do manual access requests become a security problem?

Why This Matters for Security Teams

Manual access requests often look harmless because they sit inside approved IT or IAM workflows, but they become a control failure when approval depends on inbox timing, informal judgment, or inconsistent reviewer practice instead of enforceable policy. That is especially risky for NHIs, where access is frequently machine-to-machine, high volume, and time sensitive. NHI Mgmt Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means manual handling does not scale cleanly.

The problem is not just delay. Every manual step increases the odds of over-approval, stale access, weak audit evidence, and inconsistent separation of duties. For autonomous or semi-autonomous systems, the security impact is sharper because access often needs to be scoped to a task, not a job title. Current guidance from the OWASP Non-Human Identity Top 10 also points to excessive privilege and poor lifecycle control as recurring NHI risks. In practice, many security teams encounter the abuse of manual approvals only after access has already been reused, expanded, or left active far longer than intended.

How It Works in Practice

Manual requests cross the line from governance to risk when they become the mechanism by which entitlements are created, extended, or revived without strong policy enforcement. A secure process should make humans reviewers of policy, not the source of policy. That means defining who can approve what, for which system, under what condition, with what expiration, and with what evidence retained for audit. For NHI-heavy environments, this is where 52 NHI Breaches Analysis is useful because it reinforces how often identity failures are really lifecycle failures.

• Use pre-approved entitlement patterns for standard access so low-risk requests do not need ad hoc review.
• Require contextual approval for exceptions, including business justification, system sensitivity, and time bound expiry.
• Pair requests with just-in-time provisioning so access is issued only for the task and revoked automatically on completion.
• Route NHI access through workload identity and short-lived tokens rather than shared or static secrets.
• Log the full decision path, including requester, approver, policy, expiry, and revocation event.

For many organisations, the right answer is not to eliminate manual approvals entirely, but to make them the exception. Best practice is evolving toward policy-as-code and runtime checks rather than email-driven access grants, especially where request volume is high or role changes are frequent. The OWASP Non-Human Identity Top 10 aligns with this by treating over-privilege and secret sprawl as structural issues, not one-off mistakes. These controls tend to break down in fast-moving DevOps and multi-cloud environments because request queues cannot keep pace with ephemeral workloads and short deployment windows.

Common Variations and Edge Cases

Tighter approval workflows often increase operational friction, so organisations have to balance speed against assurance. That tradeoff matters most where the system is regulated, customer-facing, or tied to production access, because the cost of a bad approval is far higher than the delay caused by a stricter gate.

There is no universal standard for this yet, but current guidance suggests three common exceptions where manual requests still make sense: emergency break-glass access, rare privileged changes, and exceptional third-party onboarding. Even then, the approval should be time limited, fully logged, and reviewed after the fact. For agentic or automated workloads, manual ticketing is usually the wrong default because access patterns are dynamic and task driven. The Ultimate Guide to NHIs - Key Challenges and Risks highlights how poorly controlled secrets and over-privileged NHIs create persistent exposure long after the original request is forgotten.

Manual access requests also become a security problem when they are used to mask missing role design, weak offboarding, or absent inventory. If approvals are compensating for bad IAM architecture, the queue will keep growing while the risk becomes normalised.

Related resources from NHI Mgmt Group

• How should security teams govern access requests through IT service management tools?
• How should security teams separate access requests from privileged access management?
• When does break-fix IT become a security risk rather than just an efficiency problem?
• When does role-based access control become a poor fit for application security?