What breaks when organisations rely on manual permission granting?

Why This Matters for Security Teams

Manual permission granting looks harmless when the request volume is low, but it becomes a control failure as soon as identities, apps, vendors, and automation multiply. Every exception created by hand needs someone to remember why it exists, when it expires, and who approved it. That is exactly where drift begins. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Key Challenges and Risks, which makes manual access decisions especially hard to audit.

The practical problem is not just overpermission. It is that human memory becomes part of the control plane, and human memory does not scale. When access is granted manually, it often survives the project, the contractor, the integration, or the incident it was created for. That is why guidance from the OWASP Non-Human Identity Top 10 treats weak lifecycle governance as a real exposure, not a paperwork issue. In practice, many security teams encounter excessive access only after a breach review or a failed audit, rather than through intentional access design.

How It Works in Practice

Manual granting breaks because it depends on static judgment in a dynamic environment. A human approver can interpret a request, but they cannot reliably predict how an identity will be used six weeks later, especially when the identity is a service account, API key, or third-party integration. Over time, role definitions accumulate exceptions, and those exceptions become the real system of access. This is why current guidance suggests replacing one-time approvals with policy-driven, time-bound access decisions.

In mature environments, permissioning is tied to a clear workflow: request, justification, approval, expiry, and review. The controls work best when they are automated, because the system can enforce consistency even when staff changes, incidents happen, or business units reorganise. For non-human identities, this usually means pairing least privilege with strong lifecycle controls and visibility into every credential and entitlement. The Ultimate Guide to NHIs — Key Challenges and Risks also highlights how limited visibility makes this worse when service accounts are spread across code, CI/CD, and cloud platforms.

• Use role templates for common access, but require expiry on every exception.
• Separate approval from provisioning so no single person can grant and persist access unchecked.
• Review permissions against actual use, not just against the original request form.
• Track ownership for every app, service account, and vendor identity so revocation has a clear accountable party.

This aligns with the operating model described in the OWASP Non-Human Identity Top 10, where unmanaged lifecycle and excessive privilege are treated as common failure modes. These controls tend to break down when organisations route access through informal chat approvals and never reconcile those approvals back to authoritative identity records.

Common Variations and Edge Cases

Tighter permission controls often increase operational overhead, requiring organisations to balance speed against auditability. That tradeoff is real, especially in engineering teams that rely on rapid experimentation or frequent vendor onboarding. Best practice is evolving, but there is no universal standard for how much manual approval is acceptable before it becomes a liability.

Some organisations try to keep manual review only for high-risk access, while allowing low-risk access to flow through predefined policy. That can work, but only if the boundary is explicit and regularly tested. Others keep manual exceptions for legacy systems that cannot support automation, yet those environments need compensating controls such as shorter review cycles, stronger logging, and forced expiration. The strongest models treat manual approval as an exception path, not the default operating model.

The risk becomes even more pronounced when permissions are granted to shared service accounts, contractors, or vendor-managed integrations, because ownership is unclear and revocation is often delayed. NHIMG data shows 92% of organisations expose NHIs to third parties, which helps explain why manual processes struggle once access crosses organisational boundaries. Security teams should also pair this with the standards view in the OWASP Non-Human Identity Top 10 and the broader risk framing in the Ultimate Guide to NHIs — Key Challenges and Risks.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on a single analytics service for every workload?
• What breaks when organisations rely only on blocking unapproved AI tools?
• What breaks when organisations rely on quarterly access reviews?
• What breaks when organisations rely only on SASE?